Hi everybody, Thanks for highlighting this in a public thread.
Before switching to snaps, please consider mongodb lifetime as snapd does not give you any strict lifetime guarantees as of now: 1. it will try to stop a service on update; 2. will send SIGTERM if that timed out; 3. if processes in the unit's cgroup are still alive after a SIGTERM timeout it will SIGKILL all of them. Now, it might be a good idea from the first sight to keep stuff updated, but I do not want to be in a situation where I have to explain to a customer that his model is corrupted due to an update that happened during his 100-node deployment or an update process where there have been a high volume of traffic preventing the mongodb service from stopping. Even if a database could be recovered after a forced crash, filing charm bugs and restoring a correct state after some lost events would be a nightmare. It is a question of update safety which is quite generic. Please take a look at the forum thread below and an e-mail thread. I had exactly the same question for libvirt and QEMU. This is valid for any critical services such as LXD, docker, openvswitch etc. https://forum.snapcraft.io/t/process-lifecycle-on-snap-refresh/140 https://lists.ubuntu.com/archives/snapcraft/2017-March/003674.html https://bugs.launchpad.net/snappy/+bug/1632508 Just follow the code path below and you will see it: https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapstate.go#L582-L601 https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapstate.go#L113-L123 https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapmgr.go#L324-L326 https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/handlers.go#L770-L791 https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/backend/link.go#L81-L83 systemctl stop -> SIGTERM -> SIGKILL https://github.com/snapcore/snapd/blob/release/2.26/wrappers/services.go#L107-L127 The actual implementation which just calls systemd: https://github.com/snapcore/snapd/blob/release/2.26/systemd/systemd.go#L279-L323 Or, in a single paste but for an earlier version https://paste.ubuntu.com/24262077/ ---- Have you guys considered that? I understand Juju client updates but we should really be careful about mongodb updates. This is a critical point to consider - please don't ignore it. --- LXD and snapd: squashfuse must be installed in a container in order for this to work. Unless you have that, you cannot mount a squashfs file system as there is no CAP_SYS_ADMIN for unprivileged containers: http://man7.org/linux/man-pages/man7/capabilities.7.html "CAP_SYS_ADMIN ... Perform a range of system administration operations including: ... mount(2), umount(2),..." https://lwn.net/Articles/486306/ snapd does not depend on squashfuse currently: https://packages.ubuntu.com/xenial-updates/snapd https://packages.ubuntu.com/search?keywords=squashfuse --- Offline upgrades: A CDN is used to distribute snap packages, hence, this requires a more careful handling for offline environments. See my answer here for hostnames I have found to be used: https://lists.ubuntu.com/archives/juju/2017-March/008795.html Technically, a snap store is a web application giving certain files away by virtue of a REST API. https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex Somebody even tried creating their own bare-bones snap store but this story is not production-ready yet in my view. https://github.com/noise/snapstore Hence, for the field team to use it, we need to have a good story for that - it would make our live much harder if there wasn't any verified solution for this. --- I am open to any feedback regarding auto-updates and offline updates as this will directly impact what I do. Thanks in advance. On 23 Jun 2017 09:08, "Danilo Šegan" <dan...@canonical.com> wrote: У пет, 23. 06 2017. у 09:00 +0200, Danilo Šegan пише: ...there's no way to do lock-step upgrades... That's, of course, too strong. What I meant was that there is no way to do lock-step upgrades while using the default daemon specifications: you can always decide to do the systemd control of services yourself. Cheers, Danilo -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
