Get a way to differentiate uninstall/shutdown from snap update in stop script

[Stéphane Graber]

LXD as you known is a daemon which runs a bunch of containers.

There are two ways to shutdown LXD:
 - Daemon shutdown
 - Full system shutdown

In the first case, LXD itself will exit but all containers will keep running. When LXD is started again, it'll start managing the running containers just fine. That's what we do during package updates in Ubuntu, allowing for LXD to be upgraded without any downtime for the containers.

The full system shutdown, has LXD properly shutdown all the containers by sending them the appropriate shutdown signal, then marks all those containers for restart when LXD is next brought up (equivalent to power-on-last-state for physical machines) and finally exits.

With our current snap, we couldn't find a way to detect the following cases:
 - Package is uninstalled (containers should be instantly killed, storage pool unconfigured, ...)
 - Package is being updated (containers should keep running, lxcfs should keep running, lxd exits)
 - Host is being shutdown (containers should be cleanly shutdown and remembered then lxd exists)

So right now, we're just always assuming the clean shutdown case. This means that LXD snap upgrade can take quite a while as all containers must shutdown, sync their data to disk, then lxd can be upgraded and the containers restarted. This causes some obvious downtime which isn't ideal when snap updates can happen at any time.

It also means that removing the LXD snap can be problematic as there may be stray mounts keeping things like the ZFS pool active which may cause package removal to fail entirely.

As a packager, I'd love to have the ability to specify different stop scripts for those 3 cases. I realize this doesn't map the systemd unit format too well, so some wrapping may be needed there.

In the deb world, we deal with this by having a lot of extra logic in our maintainer scripts to determine whether we're installing, upgrading or removing LXD. Only starting/stopping the right systemd units depending on that and have a dedicated unit just for host boot/shutdown.
I don't really want to replicate that complexity, so hopefully snappy can achieve similar (reasonable common) goals without the need for complex scripting.

[Ian Johnson (anonymouse67)]

Do the pre-refresh, post-refresh and remove hooks solve this bug for folks? If so I would like to mark this as FixReleased

[Stéphane Graber (stgraber)]

I think so. We have our own mitigation for this issue which doesn't use the new hooks but we do use the remove hook now.

If someone wanted their service to just be reloaded rather than restarted on refresh, they should be able to write a flag in pre-refresh, check for the flag in their stop script and clear the flag in post-refresh.