before the release of the new disaster recovery tool I used the import command lxd import foo --force
to import containers inside my restore-scripts that sync’ed the data beforehand by rsync into the appropriate directory.
In this restore-process the container name foo might have been changed from the original name with intension. For example to setup a test environment from a rsync backup of a production environment with a different container name.
It would be great to extend lxd recover in the following way:
a flag for non-interactive execution
with a parameter that refers to the recovery of a specific container
and a ‘–force’ parameter that ignores a difference between the container name in metadata.yml and the given container name parameter in the command
Note that we’re not very likely to do anything to make lxd recover be used for anything other than its goal (disaster recovery).
Yes, it was possible to script lxd import but we’re yet to see any case where this was done to perform disaster recovery. Those commands rely on pretty dangerous internal APIs and are really really not meant to be run automatically, they should be run when dealing with a disaster situation and then have an administrator re-check all the imported stuff to make sure that nothing broke.
Hi, imagine that you have been using something for many years without any problems and suddenly there is practically no replacement that would allow a quick fix without having to use an older version. It’s so sad for me.
I don’t think it’s wise, especially because it breaks backward compatibility.
I have a couple of custom-scripts that I use to migrate containers if necessary, which I migrate using zfs send / receive, mount through nsenter + lxd import container-name --force.
After upgrading to the latest version (after a long force-version in the snap) it’s just broken, lxd import said it can’t --force, if I try it without it, it will refer me to lxd recover, and this command cannot be used non-interactively or only for one defined container.
Please, can you consider, at least, to return the lxd import command in its original form and functionality, in order to maintain backward compatibility?
You mentioned you were using lxd import to migrate, can I ask why you are not using lxc copy or lxc move to do this (which will use zfs send/receive under the hood) as that would be the recommended and supported way to migrate an instance.
Also, yes. Backup can be done using various tools and restored at different locations. IMHO the lxd recover (alias lxd import) tool could support importing more directly, considering the flexibility of real-world environments. Thank you!
Because my scripts which uses my rules have shortest downtime than copy/migrate via your official tools.
Its practically non-sense to explain reasons. The reality is that you have broken backward compatibility, and we are asking for this situation to be rectified, nothing more, nothing less.