While not documented as the way to restore Krill Manager from a backup one can imagine someone using the cloud (e.g. AWS or DigitalOcean) ability to make backup images and then attempting to restore from one at some point.
This fails, badly. When attempting any krillmanager command on the new VM launched from the backup image it hangs for a couple of minutes then finally errors out with a message like this:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/plugins/1df81a52b95ae791894c96de267e7336bb1a168876fef6c1b897d50cbdb48938/propagated-mount/315d5e91ef2a5cee74e277360a2d395160a60c57f99ac65d83889b1b1e91377c\\\" to rootfs \\\"/var/lib/docker/overlay2/63886b82dd82e31672ed258c9643e6a53f6462d1d239e424c717dcf2bd636af8/merged\\\" at \\\"/data\\\" caused \\\"stat /var/lib/docker/plugins/1df81a52b95ae791894c96de267e7336bb1a168876fef6c1b897d50cbdb48938/propagated-mount/315d5e91ef2a5cee74e277360a2d395160a60c57f99ac65d83889b1b1e91377c: transport endpoint is not connected\\\"\"": unknown.
This is in some way a problem with Docker and Gluster. One cannot even use krillmanager restore to recover as that also requires launching a Docker container using the Gluster volumes and fails the same way. At the very least a quicker response with a more useful error message and some ability to recover would be nice.
One solution to this would be if the krillmanager command were not itself dependent on Docker.
Note: The currently documented way to restore from backup is to launch a fresh Krill Manager instance, upload (e.g. via scp) a backup archive previously made on the old instance using krillmanager backup, and to run the krillmanager restore /path/to/backup.tgz on the new instance.
While not documented as the way to restore Krill Manager from a backup one can imagine someone using the cloud (e.g. AWS or DigitalOcean) ability to make backup images and then attempting to restore from one at some point.
This fails, badly. When attempting any
krillmanager
command on the new VM launched from the backup image it hangs for a couple of minutes then finally errors out with a message like this:This is in some way a problem with Docker and Gluster. One cannot even use
krillmanager restore
to recover as that also requires launching a Docker container using the Gluster volumes and fails the same way. At the very least a quicker response with a more useful error message and some ability to recover would be nice.One solution to this would be if the
krillmanager
command were not itself dependent on Docker.Note: The currently documented way to restore from backup is to launch a fresh Krill Manager instance, upload (e.g. via scp) a backup archive previously made on the old instance using
krillmanager backup
, and to run thekrillmanager restore /path/to/backup.tgz
on the new instance.