I see in https://lxd.readthedocs.io/en/latest/environment/
that it’s supposed to be possible to set the server environment, particularly the PATH.
From the doc, I have absolutely no idea on how to do that with Snap LXD (systemd control file is marked DO NOT EDIT) and I doubt very much that it is possible at all to set the PATH env variable for the LXD server when using the Snap version.
Is there somewhere a doc for the snap specific “features” (restrictions) of LXD ?
BTW given the extensive use of snapshots in LXD, the search for ‘snap’ in the documentation search engine is not useful at all.
What are you trying to add to the PATH environment variable?
The snap runs with its own read-only filesystem so it normally can’t see any binary outside of what it ships with, making modifying PATH usually pointless.
I would like to add a directory where I could copy the pigz utility, since I noticed that the ‘compression algorithm’ was in fact the name of an executable file. I tried the change on lxd 3.03 (obviously for image compression only) and it worked all right, with a nice performance improvement. For lxd 3.03 there is nothing else to do than just apt install pigz of course, lxd just picks the system utility.
Since the gzip part of export takes more than half of the duration of export, I am dreaming of a nice speed boost. In fact I am hoping that it would shrink the total export time by half even with my smallish 4 processors system.
Oh thanks, that’s a funny trick to know. Hope you will not be cautioned by snap folks for breaking their security model :-).
I did not get my 50% improvement, sadly. My export time goes down from 14 mn to 10, only 30%. If I was not such a miser I would have been closer with more than 4 processor. Pigz has lived to its reputation, result was marginally smaller than last backup with gzip and imported flawlessly into another lxd instance.
I have found the adding, the project is at https://github.com/lxc/lxd-pkg-snap
In a way, this answers the initial question: there is no place to document the snap LXD features, since there is no README.md in the github repo. Out of curiosity, how is the packaging tested? there is code in the repo, and the lxd coverage don’t seem to well, cover snap packaging.
What’s striking is that for Ubuntu only the LTS versions are tested.
So people going on LXD with say Ubuntu 19.04 are in fact living more dangerously that they could think given that most of LXD developers are employed by Ubuntu ! for example this post: not sure if was Digital Ocean’s fault in fact.
Another point is that the tests are done with Alpine containers, because (obviously) it is making for a very quick test, but Alpine is an extremely atypical distro. The test is that a container can be launched, but there could be lot of raisons an Alpine container could be used and not a more classic distro (think systemd, for example - with current Snap on an Ubuntu 18.04 host, a jessie containers don’t start correctly and it’s linked to systemd); Here again people expecting that Ubuntu containers should always be safe are possibly too hopeful. All right, I am pushing it because manual testing by Ubuntu developers is certainly done with Ubuntu distros.
Now, what I really wanted is to find out what is in a given snap. It’s not really obvious since there is no trace of the snap building, but it’s possible to infer that the latest-candidate branch is the one used to build the snap. There is no git release tag :-/. Given the commit dates and the jenkins dates, I have concluded that the pigz change is in the stable channel. Confirmed, pigz is accepted :-). I just have to wait for next backup to see in a real life case how much time is saved. Now for the backup expiration, I think it’s not yet on 10972 given it has been added to the branch only 8 hours ago.
For testing, we also have a daily test of every single image on the image server which is run separately to validate that all images work with the current stable LXD, that saves us from testing with heavier images in other tests.
As for 19.04, we’re quite a bit behind on creating all the test VMs needed for a variety of distros, including Ubuntu, it’s on my TODO list. just not very high on it.
The majority of the LXD developers (myself included) run Ubuntu 19.04, so any breakage there will be noticed very quickly.