On 31/01/2016 17:08, Guillermo wrote:
> So, are you willing to share the plans for this? I take it you'll
> write, or help the distribution's developers do so, s6-rc service
> definitions for Alpine so it will be able to boot with s6 + s6-rc, as
> an alternative to BusyBox init + OpenRC?
Yes. It's still very vague and nebulous at this point, and I probably
won't have time to really work on it before next autumn at least, but
that is the general idea.
Before writing those definitions, though, there's important preliminary
work to do: separating existing packages that include an init script into
package-mechanism and package-policy-openrc. This can be done without
breaking anything. And when it is time to write package-policy-s6rc, it
can work with package-mechanism out of the box.
> Have you decided *how* you are going to do it
> (based on Alpine's existing OpenRC service scripts, etc.)?
No, not yet. The conception phase is an integral part of the project,
and it will take some time, and be done in close cooperation with the
Alpine maintainers because I'm not sure how crazy I'll be allowed to go. ;)
The logical way to do it, from afar, seems to be:
* identify the set S of packages needing an init script
* for every package x in S, split x into x and x-init-openrc
* if necessary, modify apk to understand the new dependency constraints,
which will be more complex:
using package x and service manager y => depend on x-init-y
* also make sure the initramfs is servicemanager-agnostic, which is not
the case for now. ncopa wants to completely rewrite the initramfs in a
clean way at some point; this would be the perfect opportunity.
* automatically, as much as possible), create trivial x-init-s6rc
packages from x-init-openrc (defining a oneshot even for daemons)
* at this point, the switch between service managers can be done at any
time without breaking anything.
* incrementally work on x-init-s6rc packages to make them more idiomatic,
use supervision for longruns, etc. This is the long and difficult part,
which has to be done manually and requires brain power. But with this plan,
it can be done one package at a time, and even across distro releases:
while a package hasn't been processed yet, it is still managed by s6-rc,
things still work - it's just that daemons are not supervised.
Two interesting questions will be the need for a UI (colored display
etc.) and the logging policy. Those will probably be for Alpine people
to decide.
My current work involves building a mini-distro, on which I have almost
full powers; so I'll obviously use this as an opportunity to do a real-life
test of s6-rc, smooth out the rough edges and gain some experience in
writing idiomatic service definitions. Some of the work should be directly
reusable for Alpine, eventually.
Note that replacing the service manager is independent from replacing
the init. Ideally it should even be possible to use s6-rc with a
supervision tree rooted in bb init - it's a redundant setup, but not a
broken one. Supporting all cases can be done before working on the
s6-rc packages, or afterwards, or even in the middle of it: it does not
matter.
--
Laurent
Received on Sun Jan 31 2016 - 18:19:15 UTC