4 ms·

Snap auto updates brought down a 4 node Raspberry Pi 4 lxd cluster I was running in my home lab. One of the nodes went down and before there was a chance to add

by tssva 6y ago

Snap auto updates brought down a 4 node Raspberry Pi 4 lxd cluster I was running in my home lab. One of the nodes went down and before there was a chance to address it snap decided to auto update lxd on the remaining nodes. Since the down node wasn't updated this caused the entire cluster to fail because not all the cluster members were on the same lxd version. I was able to force remove the down node from the cluster to bring things back up. As soon as possible I moved away from lxd which is a shame. It met my needs better and was easier to manage than k3s which replaced it. Unfortunately as long as it is only available as a snap it is a non-starter for my lab. I don't see how it could possibly be considered for a real deployment.

julianlam 6y ago
Seriously? You aren't able to install LXD via apt any more? Suppose that's what you get when a product is owned by Canonical...
- jlokier 6y ago
  That's right. You used to get LXD over APT but they changed it and now you can't. Well there's an APT package, but it simply tells Snap to install using Snap. You can do the latter yourself and get the same result either way. Most of my servers use LXD for containers, and started doing so when it was over APT like any other package. Then it was like a much improved LXC, and pretty nice. Things "just worked". It's just as well it's like an improved LXC, because the commands are both "lxc" -- to maximise confusion! I need both old-style LXC and new-style LXD-pretending-to-be-LXC installed at the same time, because some LXC container images fail to run under LXD. The change to forcing Snap is literally the only use of Snap on my host servers now. It's annoying and disconcerting. I'm still not sure if it will auto-update or not, and I daren't find out by switching to the current version of LXD. I'm sticking with an old version, which seems safer! I could study Snap and get to know it, but that seems silly given I don't use it for anything else. It's also annoying because of the mount points and data isolation inside Snaps, which I've basically had to workaround. I appreciate the benefits of container isolation, of course, but it did require some bind-mounting to accomodate my existing images and configurations. In due course I expect I will switch out LXD for Kubernetes. That will be a pain, because K8s/Docker are not optimised for running distro images, but I don't think the pain will be any worse than trying to obtain certainty about LXD+Snap's evolving behaviour, and daily familiarity with K8s has far higher market value. Which is a shame, because LXC and LXD are great technologies, and the various packaging and relevance issues have made even old-style LXC something to move away from.
curt15 6y ago
The way canonical is pushing snap reminds me of how Google once tried to force Google+ into everything.

by tssva 6y ago

julianlam 6y ago

Seriously? You aren't able to install LXD via apt any more? Suppose that's what you get when a product is owned by Canonical...

jlokier 6y ago
That's right. You used to get LXD over APT but they changed it and now you can't. Well there's an APT package, but it simply tells Snap to install using Snap. You can do the latter yourself and get the same result either way. Most of my servers use LXD for containers, and started doing so when it was over APT like any other package. Then it was like a much improved LXC, and pretty nice. Things "just worked". It's just as well it's like an improved LXC, because the commands are both "lxc" -- to maximise confusion! I need both old-style LXC and new-style LXD-pretending-to-be-LXC installed at the same time, because some LXC container images fail to run under LXD. The change to forcing Snap is literally the only use of Snap on my host servers now. It's annoying and disconcerting. I'm still not sure if it will auto-update or not, and I daren't find out by switching to the current version of LXD. I'm sticking with an old version, which seems safer! I could study Snap and get to know it, but that seems silly given I don't use it for anything else. It's also annoying because of the mount points and data isolation inside Snaps, which I've basically had to workaround. I appreciate the benefits of container isolation, of course, but it did require some bind-mounting to accomodate my existing images and configurations. In due course I expect I will switch out LXD for Kubernetes. That will be a pain, because K8s/Docker are not optimised for running distro images, but I don't think the pain will be any worse than trying to obtain certainty about LXD+Snap's evolving behaviour, and daily familiarity with K8s has far higher market value. Which is a shame, because LXC and LXD are great technologies, and the various packaging and relevance issues have made even old-style LXC something to move away from.

curt15 6y ago

The way canonical is pushing snap reminds me of how Google once tried to force Google+ into everything.