Re: The plans for Alpine Linux

[Avery Payne]

On 2/3/2016 9:30 AM, Steve Litt wrote:


Hi Laurent,

The situation you describe, with the maintainer of a distro's
maintainer for a specific daemon packaging every "policy" for every
init system and service manager, is certainly something we're working
toward. But there are obstacles:

* Daemon maintainer might not have the necessary time.

This is probably true.



* Daemon maintainer might not have the necessary knowledge of the init
   system or service manager.
Also true.  To them it's probably "just glue that needs to be there to 
support that thing-a-ma-jig".  Look at some of the Debian init.d scripts 
sometime and notice just how butchered some are.  Some are blatant 
cut-and-paste jobs with the bare minimum to make the launch happen...


I personally feel that the first two points made represent the 
"majority" of cases, although I don't have any proof to back that assertion.




* Daemon maintainer might be one of these guys who figures that the
   only way to start up a system is sysvinit or systemd, and that any
   accommodation, by him, for any other daemon startup, would be giving
   aid and comfort to the enemy.

Not entirely sure that would be the case, but hey, anything is possible.



* Daemon maintainer might be one of these guys who tries to (example)
   Debianize the run script to the point where the beauty and simplicity
   and unique qualities of the service manager are discarded.
Given how Debian works (examples: alternatives, package and repository 
licensing, etc.) I would be surprised if this DIDN'T happen.  Debian 
software really wants one way to deal with multiple choices, so there 
would probably be some kind of glue scripts that would make the 
appropriate calls, etc.


Just my .05 cents.

Re: The plans for Alpine Linux

[Laurent Bercot]

On 03/02/2016 18:30, Steve Litt wrote:

The situation you describe, with the maintainer of a distro's
maintainer for a specific daemon packaging every "policy" for every
init system and service manager, is certainly something we're working
toward.


 This is certainly a possible, even a desirable, setup, but it is not
necessary. One of the advantages of small package granularity is that
you have more flexibility in maintainership - you don't have to assign
the same maintainer to all the packages in a set. And that overcomes
most of the obstacles:



* Daemon maintainer might not have the necessary time.


 Not a factor for the initial split: there isn't more total code.
Could become a factor when you add service managers, but the amount of
maintenance needed for 2 or 3 service managers should remain negligible
before the amount of maintenance needed for the daemon itself.



* Daemon maintainer might not have the necessary knowledge of the init
   system or service manager.


 Then acquire it. You're a maintainer for a distribution? You better
know how your distribution works. How all supported ways of starting
your daemon work. That's your job as a maintainer.

 If it's really not possible, assign the maintainership of the package
with the new service manager policy to someone else, who knows the new
service manager.



* Daemon maintainer might be one of these guys who figures that the
   only way to start up a system is sysvinit or systemd, and that any
   accommodation, by him, for any other daemon startup, would be giving
   aid and comfort to the enemy.


 If you're disagreeing with the political choices of a distribution, why
are you sticking with that distribution?

 See above: don't make people maintain things they don't want to maintain.
Find someone else who will. Small granularity to the rescue: I certainly
do not want to maintain mysqld, but I could probably be talked into
maintaining mysqld-init-s6rc if there was absolutely nobody else for the
job.



* Daemon maintainer might be one of these guys who tries to (example)
   Debianize the run script to the point where the beauty and simplicity
   and unique qualities of the service manager are discarded.


 That is a common risk with every package, and is orthogonal to the amount
of supported service managers, or their nature.

 I am not saying the obstacles are not real, or hard to overcome. I realize
they most certainly are. I am saying that the issues you are raising are
all of a human nature, not a technical one, and at this point that is not
what I want to focus on. When designing a solution, I am passionate about
being dispassionate; if the path to technical excellence is riddled with
hardships the only possible answer to is "get better maintainers", then
so be it. There will always be time to compromise later.

--
 Laurent

Re: The plans for Alpine Linux

[Steve Litt]

On Sun, 31 Jan 2016 13:08:33 -0300
Guillermo  wrote:

> From this thread:
> 
> http://www.mail-archive.com/supervision@list.skarnet.org/msg01123.html
> 
> 2016-01-27 9:16 GMT-03:00 Laurent Bercot:
> >
> >  The biggest hurdle that *every* distribution faces is that every
> > daemon starting script is specific to the service manager, and
> > supervision systems do things very differently from non-supervision
> > systems.
> >
> >  And so, daemon packages need to be separated into "mechanism" (the
> > daemon itself) and "policy" (the way to start it), with as many
> > "policy" packages as there are supported service managers.
> >
> >  I plan to do this work for Alpine Linux towards the end of this
> > year; I think most of it will be reusable for other distributions,
> > including Buildroot.  

Hi Laurent,

The situation you describe, with the maintainer of a distro's
maintainer for a specific daemon packaging every "policy" for every
init system and service manager, is certainly something we're working
toward. But there are obstacles:

* Daemon maintainer might not have the necessary time.

* Daemon maintainer might not have the necessary knowledge of the init
  system or service manager.

* Daemon maintainer might be one of these guys who figures that the
  only way to start up a system is sysvinit or systemd, and that any
  accommodation, by him, for any other daemon startup, would be giving
  aid and comfort to the enemy.

* Daemon maintainer might be one of these guys who tries to (example)
  Debianize the run script to the point where the beauty and simplicity
  and unique qualities of the service manager are discarded.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28

Re: The plans for Alpine Linux

[Laurent Bercot]

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