apply: better define what "early-boot" means

[lucab]

I submitted the initial service unit I'm using in #34. As part of system integration, we need to define to better define the "early-boot" story and capture it in devdoc.

I'm currently using this very weak anchoring:

WantedBy=sysinit.target
RequiredBy=basic.target

Other datapoints:

• torcx.service is a oneshot unit, so it'll block targets progression till the final sealing is done (or the service fails)
• some addon services handled via torcx will be part of the dependency graph (docker, containerd, rkt-api) so it would be better to extract them as early as possible
• torcx-apply doesn't fetch, so it doesn't strictly need a network'd target
• torcx-apply doesn't depends on dbus service/socket
• torcx-apply needs local-fs to be in place, in particular it relies on /tmp, /var and /run
• some users may provide images via a NAS volume, thus depending on remote-fs.target. I think this usecase can and should captured via an user drop-in

The outcome of this ticket would likely be an upper and lower bounds (as in targets and services) to place torcx.service in-between.

/cc @euank @crawford @marineam

[squeed]

This is going to take some careful thought.

For example, the sockets.target starts very early in the boot process. We're basically going to want to start before any other target, so we can install any "wants".

[marineam]

A couple things, ordering is managed by Before/After, not wanted/required.

Changing service dependencies during boot, although possible, is a very dangerous. We abandoned coreos-cloudinit for this very reason.

It sounds to me like this is a sufficently constrained job that it may be practical to run it as a generator instead of a service. Generators run right when systemd starts so you can only depend on /etc and /run (you will be given a set of paths in /run as arguments where the app can write service files and create .wants links.) Be warned, at this point even /tmp is not reliably available. The key is running so early is you ensure systemd actually respects the changes you make. Making dependency and service charges any later is essentially a sure fire way to have an endless stream of bugs.

[squeed]

One thought that I had while Luca and I were staring off in to space: Perhaps all packaged services need to be wanted by a special torcx-package.target. We might be able to constrain the dependency changes sufficiently that we don't find ourselves in such a world of hurt.

And, maybe not.

[lucab]

Current status is that we are slowly adapting torcx to be a generator (see #37), with a small twist.

As we don't plan to handle runtime upgrades, generated units are written directly to the runtime directory only on the first run before sealing the system. On subsequent daemon-reload, generator detects that the system is already sealed and just stops there. We also rely on the fact that inignition and cl-initrd already set up / and /usr, to pick up vendor packages and other bits from there. Apart from that, we only ever unpack/propagate files to /run.

[squeed]

Just a final update: torcx is now completely run as a generator; this is done.