Service ordering

[chipaca]

(I thought I’d created this topic ages ago, but can’t find it; apologies for either the duplication or the tardiness).

We want to have an (explicit) way of ordering services within a snap. I think just supporting an “after” keyword in services would be enough. This would look like

apps:
 foo:
  command: bin/start-foo
  daemon: simple
 bar:
  command: bin/start-bar
  daemon: simple
  after: foo
 baz:
  command: bin/start-baz
  daemon: simple
  after: foo

Also perhaps a way (behind an interface?) of ordering services of a snap to services “outside” (note this is ordering and not dependencies, so for example you can have a snap that depends on a database service, and you ship with a sqlite backend but also support connecting to the system’s postgres if there is one, you could do it with this). Ideally we’d use after: <some magic> to not complicate the yaml more with this, but atm I don’t know what the magic would be (it would have to be clear and obvious to the reader and writer, and at the same time not lead to things like a snap shipping a postgres app and having that after get confused with the postgres service from “outside”. This needs more discussion obviously and would probably come in a second phase, but I thought it worth mentioning here.

[zyga]

I like the explicitness of this. I suspect most people won’t use this but those that do will appreciate the clarity.

[niemeyer]

Proposal looks nice indeed.

For the more complex case, we may be able to introduce ordering support somewhat implicitly via interfaces themselves, instead of expecting snaps to magically know about each other. In other words, if we have a slot on provider.app and a plug on consumer.app, it seems reasonable to order the startup of the daemon in the former before the daemon in the latter.

There are surely details to figure out, but this sounds like a reasonable direction to explore at least.

[kyrofa]

I like this as well. @niemeyer to clarify for phase 2, you’re saying all the daemons in the provider should be running before we start any daemons in the consumer? Not the most efficient, but definitely the simplest and pretty much sure to work.

[niemeyer]

Yeah, something along those lines. It’s not so simple because there may be loops, so not every interface will be treated the same, and we may need to introduce more explicit hints to solve non-trivial cases. But it may solve most of the easy cases transparently, and does feel like a direction worth exploring.

[ogra]

note that the original request and discussion was Snap service start ordering

[chipaca]

… and this might be continued in the Expose a more consistent subset of systemd’s service directives topic.