I see, They have zero plans for anything else than Ubuntu.
As soon as you drop support, everything else on LXD is gone.
1 Like
The image servers are basically just static web server with HTTPS that serve a bunch of static files as well as two JSON index files (/streams/v1/index.json and /streams/v1/images.json) following the simplestreams format.
LXD/Incus also keeps a local cache of the images for 10 days since the image was last used, so even if the image goes away, so long as you keep using your local copy of it, you’ll be fine in theory indefinitely (albeit stuck on an old image).
No, we don’t really want to go down that path as it would come with some amount of expectations that the images are working. And as we need to stay as far away from LXD as we can to avoid any potential accusations of taking in features or bugfixes following their licensing change, we’re just not going to take any chances.
We don’t have any control on what does or doesn’t make it to LXD LTS.
In theory, it’s indeed bugfixes only, but some of those bugfixes can be changes to how the UEFI firmwares are handled, or I guess more likely in the case of LXD, a backport to the changes of DMI vendor IDs and serial port naming. Those kind of changes are the kind of things that have a tendency to break on those images.
And again, we can’t keep an eye on those changes anymore without getting into dangerous territory due to the license change, so if there’s something in there which breaks our images, we won’t know about it until it actually rolls out to production users.
2 Likes
Maybe we can keep this page up to date with the current LXD situation.
I ran into that page a few days ago. I suspect it will pop up in search engines, and it seems like a good source of truth for the topic.
2 Likes
Could you clarify which images you plan to phase out? Do you mean phase out LXD access to images: or phase out certain images for everyone?
1 Like
From what I gather, LXD support will be removed from images.linuxcontainers.org entirely. If you look at the dates 2024/05/01 all LXD users will lose access.
1 Like
Yeah, that’s right, it’s about the images: remote for LXD users. Those who use ubuntu: or ubuntu-daily: won’t be affected, neither will users of any other software using our image servers (LXC, Incus, OpenNebula, …).
For each set of users (per timeline above), we’ll first do a week where only the top 4 most popular images will be offered then after that week all images will disappear for those users.
2 Likes
A brief update from Canonical can be found here: An update on the licence change and community image server - News - Ubuntu Community Hub
2 Likes
Just a quick note that we have updated the roll out plan a tiny bit.
Due to LXD 5.20 still not having rolled out to stable snap users, we were concerned that LXD 5.19 users would get quite surprised when they’d lose image server access completely on February 1st.
So we’ve now added an intermediate step, kicking in on the 22nd of January which will have those same users get restricted to the top images, same as what happened to LXD 5.20 users on January 1st.
So week before last, I used LXD and images:ubuntu without issue, now I come back and everything is broken, I try to switch to ubuntu: and they behave differently to the images:ubuntu and it seems like I have a lot of work ahead of me to try and fix, not something I really have time for.
I am using lxd on arch 
Also seeing similar problems… We have been using images: with LXD (LTS and non-LTS) until now. Was working on some infrastructure changes for our LXD-based CI runners and discovered this weirdness with LTS-based LXD and “normal” LXD seeing a different set of images… until I found this thread half an hour ago. 
My problem is that LXD LTS does not work for our use case, because we use functionality which got released as part of LXD 5.1 (LXD 5.1 has been released), specifically the lxd image copy --profile flag…
So I’m currently stuck with an LXD LTS which doesn’t work (because we can’t differentiate the profile being used on Ubuntu and Rocky Linux-based guests, which is needed for proper operation) but can access the images, or an LXD non-LTS which works but can’t access the required images. 
Or, we can switch to Incus which is not released as a stable version yet. I’m not sure I’m willing to put this on our CI infrastructure just yet.
Sorry of this sounds very negative, I’m just frustrated after wasting some time on this today. I know this is not the fault of LinuxContainers.org. It’s just so incredibly sad to see all the extra work and pain this incurs on a lot of people in the community. 
Incus 0.x releases are as stable and on a similar schedule to LXD 5.x releases.
The reason to stick to 0.x until the first LTS isn’t too denote a lack of stability or support but simply to avoid misaligned versions with other Linux Containers projects.
Incus will jump straight to 6.0 at the same time we release LXC and LXCFS 6.0.
2 Likes
Great point @stgraber, thanks for clarifying this part. 
We have some scripts setup which currently rely on LXD, both for use in CI but also for running LXD-based testing locally. I’ll take this further internally to discuss if we want to move our setup over to use Incus or stay on LXD (and wait on Canonical’s support for other distros, An update on the licence change and community image server - News - Ubuntu Community Hub)
Thanks for the rundown @stgraber. (I also just learned of all the Canonical LXD hi-jinx, your resignation, and now, Incus.) My question is, Is there documentation on the recommended course of action for a) existing LXD installations (in order to maintain them) and b) new installations? I was planning on a major upgrade of my LXD server to new hardware and was going to migrate containers using your excellent documentation on the topic, but now I may want to reconsider. I certainly do not want to be stuck in a no-images window (although migration may not require images?) Should I wait for Incus 1.0/6.0 and will server-server LXD-Incus migration be possible? TIA,
-brmiller
Indeed the image server restrictions will not affect any existing instance or their future transfer to another server, so you’d be fine there.
Also, assuming you’re on LXD LTS, this will be the last set of users to be blocked from accessing the image server, by which point, Incus LTS will be out.
For migrations, you have two main options:
- Directly transfer instances between LXD and Incus by adding the Incus server as a LXD remote on the source server or the LXD server as an Incus remote on the destination server. This only works using normal TLS token based authentication but is otherwise functional as the migration protocol used by both LXD and Incus is currently the same.
- Install Incus on the server, run
lxd-to-incusto move everything to Incus on that server, and then, if you want to move those instances somewhere else, you’ll be dealing with normal Incus to Incus instance migration.
To repeat a comment made earlier in this thread, if you’re already using non-LTS LXD (5.x instead of 5.0.x), then you can already switch to Incus as our 0.x as the equivalent of a LXD 5.x. It’s monthly stable releases with support available.
It’s really just the LTS builds for which you’d want to wait another couple of months before we have Incus 6.0 LTS out.
1 Like
I am pretty sure this is all you need.
I don’t think there is any reason to wait. Incus 0.5 is coming out this week, and 6.0 will come at the same time as the other LXC projects.
Incus is stable and can be used in production.
1 Like
Running LXD 5.19-8635f82 via snap. I take it this is a non-LTS version? I’ll get busy on my migration then!
Indeed, that’s not an LTS build. Supported LTS builds would be 4.0.x or 5.0.x (currently 5.0.2).
I’m running Ubuntu 23.10 (Edited, original post mistakenly said 23.04) with lxd from snap - it seems that my access to the images is now limited. Am I correct in assuming there will be no incus package for this distribution (and no snap) so my only option is to build from source?
I bet the apt packages from Zabbly will work for you.
Have you tried them yet?
Also, Ubuntu 24.04 will be out in a few months. If the packages don’t work on 23.04, I am sure they will work on 24.04.
1 Like
I bet the apt packages from Zabbly will work for you.
Looks like the packages for 22.04/jammy work on mantic as well, thanks - I have to admit I didn’t even try them, assuming they won’t work with my version of Ubuntu. So far my existing instances work with incus.
1 Like