Consuming MongoDB from a Snap

[Dmitrii Shcherbakov]

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