[yjftsjthsd-h]

Does LXD still do the thing where it's only distributed via snap and therefore force automatic updates and restart? It's neat tech (especially supporting containers and VMs), but I just can't bring myself to invest in a platform that forces instability like that.

[tssva]

On Ubuntu it is still only available via snap. I used to run a 4 node Raspberry Pi 4 lxd cluster. One of the nodes failed over a weekend while I was out of town. The containers which were running on the node properly restarted on a different node. That should have been the end of it until I was back in town and could restore the node to operational status. Unfortunately later that day the lxd snap decided to automatically update. It updated properly on the 3 nodes which remained operational but of course the failed node could not update. Once the other nodes were upgraded the cluster refused to come up because the failed node wasn't running the same version of lxd as the rest of the cluster. I mean technically it wasn't running anything but as far as lxd was concerned it was running a differing version even though it was down.

I noticed the entire cluster was down because my Plex server ran on it and I couldn't watch a movie when I tried later that evening. Luckily I was able to ssh in and determine the issue quickly. Force removing the failed node from the cluster got things going again.

Lxd was quickly replaced by K3S which is unfortunate because the lxd cluster better fit my needs, except reliability, and was much easier to configure/manage.

Even for small platform edge K8S clusters I actual find microk8s much easier than K3S but that would put me back in snap upgrade hell.

[panpanna]

I hope Mark Shuttleworth and Stéphane Graber are reading this. Someone has sabotaged a perfectly good docker replacement with a series of really bad decisions.

Having said that, did you try to pin LXD version? For example

    sudo snap install lxd --channel=4.1/stable

[kwk1]

With the release of 4.6, there was a change in the way LXD handles its dqlite dependency that should mean the long effort to have it packaged for Debian will be coming to a close.

[LeoPanthera]

On Ubuntu maybe? If you don't like snap, don't use Ubuntu. LXC/LXD is not Ubuntu specific.

[yjftsjthsd-h]

That's rather the tail wagging the dog, isn't it? Besides, it kinda rules out most of the options; almost nobody packages it naively, probably because their build/vendoring/packaging process is insane (see https://linderud.dev/blog/packaging-lxd-for-arch-linux/).

[stgraber]

There are quite a few Linux distributions with native packages in their main repository, that includes ArchLinux, Alpine, Gentoo and OpenSUSE for those that I'm aware of with active package maintainers. There also are packages for Fedora/CentOS/RHEL through maintained COPR repositories and I'm sure I'm forgetting some distros.

Go can be a bit annoying to package in general and LXD was made a bit harder by also having a stack of C libraries for some bits, though with 4.6 we kicked out the need for a custom sqlite and for a coroutine library, so on the C side, outside of the C library, it's down to liblxc, libraft and libdqlite making it a bit easier to package.

For distributions that have a policy of splitting every single Go package into their own source packages (as is the case with Debian), our recommendation is to stick to the LTS release of LXD which only gets released every 2 years and where the bugfix releases don't normally alter dependencies.

The normal feature releases come out every month and those just aren't a good fit when it may take you more than a month to get any new dependency packaged independently first...

Anyway, as an upstream, we are very happy to work with packagers to get native packages in as many distribution as possible.

We do maintain the snap package ourselves and certainly do enjoy it as an upstream since it gives us very large distribution and release coverage with a single package.

Most common criticism of the snap package can be addressed with one of the mechanisms we outlined here: https://discuss.linuxcontainers.org/t/managing-the-lxd-snap/...

That being said, at the end of the day, all we care about is that our users get to run an up to date, secure, LXD. How they get is doesn't really matter to us as an upstream :)

And it's maybe interesting to point out that the majority of our userbase these days are on Chromebooks, effectively using the Gentoo ebuild package of LXD!

[panpanna]

Any comments on the WSL2 situation?

Like it or not, it is becoming an important Linux "distro".

[stgraber]

LXD works fine on WSL2 as unlike WSL1 you're now getting a full Linux kernel.

The main issue left is that WSL2 doesn't start your normal init system and so makes it harder to run a daemon... You end up having to manually start it every time which is a bit annoying.

But my understanding is that Microsoft is actively working on this and that we should have the normal init system run in some way in the near future.

[panpanna]

Shouldn't this have been communicated better?

On your own forums the best answer people can find to this situation is basically "we have moved to snaps, this is not our problem".

[cheph]

Last i tried getting it working on fedora I gave up because it was silently failing while appearing to work correctly due to the bad systemd unit files and init scripts from canonical (see https://github.com/lxc/lxc/blob/master/config/init/systemd/l... and https://github.com/lxc/lxc/blob/master/config/init/sysvinit/...)

Better things to do in life and I got what I wanted from podman with --rootfs.