Consuming MongoDB from a Snap

[Menno Smits]

Thanks for the detailed feedback Dmitrii. We will go through the areas
you've highlighted before making any decisions on this. At any rate, this
is unlikely to happen soon.

On 27 June 2017 at 08:15, Dmitrii Shcherbakov <
dmitrii.shcherbakov at canonical.com> wrote:

> 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" <danilo at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170628/8513ccbc/attachment.html>