4 ms·

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.

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.