Right, so for anyone who hasn’t seen the news elsewhere already, the Canonical team has decided to change the LXD license from Apache2 to AGPLv3 as well as require all new contributions to sign the Canonical CLA.
Now the impact on our side with Incus is going to be that we won’t be able to look at any new LXD code and so won’t be able to import bugfixes and new features from it as that would force us to also change license to AGPLv3.
For LXD users, this change may impact you if your company has any requirements as far as the licenses it allows for the software you consume. This could prevent some folks from using LXD while some others will need to go through a license review process again.
For downstream users, that is projects that consume the Go LXD packages, those need to be careful as updating their Go mod dependencies will pull in AGPLv3 code which could force their own code to have to be re-licensed under AGPLv3 to comply with the license.
There is a go-licences tool from Google which you can use to check whether you have any of the more restrictive licenses within your package’s dependency tree.
Now we’d like to kindly remind everyone on this forum that LXD support should be handled on the Canonical forum. This is even more important now that we really need to stay insulated from bug reports and changes happening in the LXD project.
Yeah, I just sent the one-line fix to support LXD 5.20 in migrations (just bumping the check from 5.19 to 5.20).
While we can’t import LXD changes into Incus, we can still add logic to lxd-to-incus to undo any DB schema change or similar that may land in LXD and prevent a migration.
I’m still hopeful that we can keep lxd-to-incus working all the way to LXD/Incus 6.0.
After that, we won’t be supporting newer versions of LXD and users will have to resort to other means of migration if they need to migrate from LXD 6.x (outside of 6.0). Such means include using the disaster recovery tooling (incus admin recover) or setting up both LXD and Incus side by side and then using incus copy to transfer the instances.
I am slowly exploring Incus as my tech-skills aren’t so great at fixing things I break. I have a question on your statement:
or setting up both LXD and Incus side by side and then using incus copy to transfer the instances.
If I may ask, how would the ‘incus copy’ work? I naively tried ‘incus add remote’ and it failed with a ‘not authorized’ (no surprise). I was assuming I should perform a lxd-to-incus migration (but I am going slow on that in case I screw things up).
lxd-to-incus is definitely the best way to handle it as it migrates everything in one go.
If you need to migrate progressively for some reason, you should be able to just install incus on the same machine that’s running LXD and then do: incus remote add lxd unix:///var/snap/lxd/common/lxd/unix.socket which should get you a functional lxd remote that you can then use for things like incus copy lxd:foo local:.
Worth noting that the incus client will fail to interact with any LXD servers that have the core.trust_password configuration key set, so you’re going to want to unset it first if it’s been set in the past.
