I certainly think we are on the same page here. I suppose its fine to indicate that upgrading the charm (thus upgrading the snap package) is going to restart your workload, and indicate that there is now a clear coupling between these events in most cases.
Additionally, once the docker daemon auto snap-refreshes to catch that latest bug-fix in the channel, its going to interrupt workload. This will work in some cases, but I think we need to look at the big picture for this use case which is largely different than just a developer installation.
For example, if you’re running a web-store at the scale of the Ubuntu Store, you’d have scaled your workers and any snap refreshes you incur (so long as they were staggered) would be load balanced and you can feesibly lose one or more nodes and that failover routing would ensure your customers aren’t impacted.
However, if they aren’t staggered, you’re going to feel that bite when your container(s) restart. That’s my primary concern is ensuring the charm retains predictable behavior, and the consumer doesn’t get bit by operational pain. I’ll see about adding this feature in the current cycle and making it a toggle option during install that defaults to true during the edge => stable release phase so we can get early adopter feedback.
This may prevent any need to change anything in snapd, but i suspect that over time we’ll shake out the questions i’m failing to come up with today.