We have a bit of a gap in testing there right now. We have automated testing on CentOS 7 but not on CentOS 8.
The snap refreshing never takes down the containers, so in the worst case scenario, the daemon itself fails to come back to life, causing the
lxc commands to hang due to systemd socket activation.
But that’s only really happening if LXD completely fails to start during the update.
The snap is fine for both server and desktop use alike, though exactly what track you follow and you refresh configuration in the server case will likely be different. I’d recommend production setup select a particular version by using the associated track. For example
snap install lxd --channel=3.21. This will prevent any bump in version unless you run
snap refresh lxd --channel=3.22, leaving automated refresh to just bugfixes rather than version bumps.
You can also configured snapd to use a particular time for the automated refreshes. In a production environment, I’d pick a time in the week during which someone is around should an issue occur.
You may also just plain block store access to snapd and only re-enable access when you want to refresh your machines.
On the paid/service front, Canonical does offer a snap enterprise proxy which allows you to have all your systems fetch snaps through it (allowing for air-gaped environments too) and letting you pin particular revisions of particular snaps. So at large production scale, you’d probably run one of those, test things on a few isolated staging system before blessing the new revision for the rest of your environment.