it has been stated on multipleoccasions that the LXD protocol is considered to be legacy and will eventually be superseded by the newer simplestreams protocol.
The first mention of such plans appeared first in 2018. I expect that LXD protocol will still be around for a while. However, this raises a few questions, as the LXD protocol is not only used for image retrieval, it rather defines a much broader interface for communication between clients and remotes. How will such a deprecation look like and what impact will it have?
images.linuxcontainers.org:8443 is a weirdly setup apache server which pretends to be a LXD server, I’m not sure I’d recommend you do something like that youself
So, I understand that a simplestream server for image distribution is much simpler to operate than a pseudo-LXD server.
Maybe it would be easier if you described your setup & what you are concerned will break.
Obviously the LXD API isn’t going anywhere but im going to go out on a limb and say simplestreams was an “upgrade” to LXD and the way images are distributed.
Start of conspiracy theory
I’m going to guess the LXD team realised that images.linuxcontainers.org probably wouldn’t scale as an LXD server & didn’t want the headache so they created a faux LXD server out of apache which would be easier to scale in the context of distributing images.
Im then going to assume that during the time this was going on simplestreams “matured” (the lack of documentation & example servers makes that a big word) and then they added support into LXC/ LXD.
I might be totaly wrong here but its fun to guess what happens at big orgs, @stgraber was i close? End of conspiracy theory
All it takes to host a simplestreams server is a .json (or some server side magic), a filesystem & bandwith. When compared to LXD, LXD requires alot of “junk” for an image server and so really, its better to host your own simplestreams server and ditch LXD for large scale distribution of images.
Its probably unlikely LXD downloading images from remotes will go anywhere but Im not privy to all the decisions going on.
Basically, it’s about setting up a private image server with support for authentication. This is well achievable with the LXD protocol, not so much with simplestreams as they don’t support authentication besides HTTP Basic Auth. My planned setup uses a normal LXD server with project restricted certificates and a few config options that prevent users from starting containers etc.
Simplestreams are basically just an image.json and index.json file with metadata that point to images in a specific directory tree. Having a (pseudo-)LXD server just adds more operational costs, that’s right.
The protocols used for images.linuxcontainers.org or other public image servers don’t really concern my undertaking. Rather I was interested in the long-term impact on the LXD protocol itself that I plan to use for a rather small-scale image server.
The simplestreams protocol rather than lxd, simplestreams is what’s recommended these days, lxd is considered legacy for that image server which is why we didn’t really notice it breaking
So I am pretty sure he is referring to just image server side of things.
We indeed started with images.linuxcontainers.org (ab)using apache rewrite rules to fake a REST API. This was always a bit awkward though as we couldn’t generate an output that would perfectly match LXD’s nor would we have been able to do any kind of filtering/dynamic listing. It also ended up being a LOT of files on the filesystem to provide just basic functionality.
Shortly after we got that one up and running, we were asked with adding the ubuntu: and ubuntu-daily: remotes. Those are served from cloud-images.ubuntu.com which is a simplestreams-only server. So that’s when we worked with the cloud team at Canonical (that “maintains” simplestreams and runs that server) to add some extra artifacts and fields so that LXD can get all the information it needs.
With that done, we then added support for simplestreams directly in LXD as a read-only image server backend and that’s what’s currently used for 99% of image downloads these days.
Simplestream comes with those advantages:
Much simpler static server
Support for artifact descriptions (data type, …) which we use to ship image deltas rather than full images in most cases
Easy to mirror
But it has downsides:
No support for private images
The single index file can become very large, significantly increasing the time it takes to lookup an image
Not made for LXD so we need quite a bit of conversion logic internally to go from simplestreams fields to LXD image fields
