* Laurent Bercot <ska-skaware_at_skarnet.org> [20150423 17:36]:
> Source, compiled and live
> -------------------------
>
> Instead, s6-rc provides a "s6-rc-compile" utility that takes the
> user-provided service definitions, the "source", and compiles it into
> binary form in a place in the root filesystem, the "compiled".
>
> At run-time, s6-rc ignores the source, but reads its data from the
> compiled, which can be on a read-only filesystem. It also needs a
> read-write place to maintain information about its state; this place is
> called the "live". Unlike the compiled, the live is small: it can reside
> in RAM.
I'd really expect a ui that can "diff" "compiled" & "live" vs. "source" (and
obviously, to inspect "compile" & "live").
> Run-time
> --------
>
> At run-time, s6-rc only works in *stage 2*.
> That is important, and one of the few things I do not like in anopa:
> stage 1 should be completely off-limits to any tool.
>
> s6-rc only wants a machine with a s6-svscan running on a scandir. It does
> not care what happened before. It does not care whether s6-svscan is
> process 1 or not.
>
> This does not mean s6-rc cannot handle one-time initialization. On the
> contrary, my view is that one-time initialization should be deferred to
> stage 2 as much as possible, with an absolutely minimal stage 1. For those
> who want to run s6-svscan as process 1 (and they're right), I intend to
> work on a s6-init package that will provide suitable minimal stage 1s
> depending on the OS and user configuration; they will start stage 2 with
> s6-svscan running on an empty scandir - save the catch-all logger and
> maybe a getty.
>
> In stage 2, the user should start by running the "s6-rc-init" program,
> which is roughly the equivalent of anopa's "aa-enable".
> s6-rc-init will initialize the live area, and also start all the
> supervisors for all the defined long-run services (so that notifications
> work properly later on). Service directories are copied from the compiled
> to the live, and initially they all have a down file so the supervisors
> are started but not the services.
It's not clear to me how early operator input can be handled, i.e:
passphrase for decrypting the keys in an attached device. Ideally, ASAP
to handle as-full-as-possible-disk-encryption.
> Down files, like the rest of service directories, are managed directly
> by s6-rc: one the user relinquishes her machine state management to
> s6-rc, she does not tinker manually with service directories ever
> again.
I find ./down so convinient that would like having support for it in the
"source" format.
> Live updates
> ------------
>
> There's a complex thing that anopa more or less evades but that I feel is
> necessary in order to be adopted by a distribution: live updates. I'm not
> exactly sure yet how to proceed, but I have a vague idea, and I would like
> more input on the subject.
>
> Users will upgrade their packages. They will sometimes need to restart
> longrun services. If not much has changed, it's easy: they can do it with
> s6-svc without touching the global state, so it's not s6-rc's or anopa's
> concern. However, sometimes things change: new daemons are introduced,
> new dependencies are introduced, etc.
>
> My view is that packages should provide source definitions, and after an
> update, the distribution should invoke s6-rc-compile again. This is easy
> enough, but then the live state does not match the current compiled
> service database anymore. anopa has a similar problem with its current
> service repository.
>
> I am thinking about a utility, "s6-rc-update", that would take the live,
> the old compiled and the new compiled as inputs, and that would update
> the live as smartly as possible, with carefully designed heuristics;
> users could also tell s6-rc-update exactly what to do via annotations in
> the source, that s6-rc-compile would translate into the new compiled.
Any heuristics will face unsolvable situations. I'd aim at getting the
"patch" (dual of "diff" above) action right all the time first.
keep up the good work
--
pica
Received on Thu Apr 23 2015 - 21:26:37 UTC