From: "Laurent Bercot" <ska-devel@skarnet.org>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Use of supervise-daemon in Alpine
Date: Fri, 21 Aug 2020 08:54:30 +0000
Message-Id: <emdc86f515-08e2-457b-a19c-2fd31e8dca72@elzian>
In-Reply-To: <5b2db58f-ad11-e4ac-eede-66dc86b3ddcf@dereferenced.org>
References: <3LLUI2KOULSYM.359WA6HATX45B@8pit.net>
 <f7b0aab5-4dc6-69f1-048d-f90f59891b45@dereferenced.org>
 <ema98f4fba-1095-4a5f-90fc-07f8ffdec5e8@elzian>
 <5b2db58f-ad11-e4ac-eede-66dc86b3ddcf@dereferenced.org>
Reply-To: "Laurent Bercot" <ska-devel@skarnet.org>
User-Agent: eM_Client/8.0.3382.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

>The main difference is that the other approach to switching to a supervisi=
on model uses a program we already ship in Alpine -- supervise-daemon(8).

  s6 is also shipped in Alpine. It may not be part of the base system,
but that is a purely political decision. And despite my efforts to
satisfy the Alpine requirements (reducing the s6 disk footprint,
reducing the number of binaries, making the execline dependency=20
optional,
etc.) the political will has constantly been lacking. So, forgive me
for not being convinced by this argument.


>While s6 may be superior to supervise-daemon, the fact that supervise-daem=
on is already in the base system *and* is explicitly designed to integrate=
 with OpenRC are the reasons it was selected.
>
>I also remember discussing s6 openrc integration with you personally, and=
 you describing it as flawed.  At the end of the day, Alpine is, at least fo=
r the foreseeable future, tied to OpenRC in some way.  While there are prop=
osals to replace OpenRC in various stages of development, we simply aren't=
 there yet.  It is possible s6 could be selected as a component of one of th=
ose proposals.

  But that's the thing: supervise-daemon does not integrate with OpenRC
any better than s6 does (barring, obviously, potential specific
interface extensions where the devs have put in the effort, which is
akin to vendor lock-in), and the flaws that exist with the s6 support as
currently implemented in OpenRC are present *in the exact same manner*
with supervise-daemon. The problem is not tied to a supervision
implementation in particular, it is tied to the way the service manager
uses the supervision system. supervise-daemon brings no architectural
advantage here; the only advantage it brings is that it is homemade by
the OpenRC team, so it reduces the number of support contact points for
you. Which is a double-edged sword.

  I know that Alpine is too reliant on OpenRC at the moment to consider
a change of service managers in the near future; that is not what I'm
talking about. What I'm saying is that there *are* ways to use s6 and
OpenRC together:
  - with the s6 support that is provided with OpenRC: it's flawed, but
not any more than the supervise-daemon support.
  - or with a small architectural redesign that ties a supervision
suite and a service manager in the correct way. The work has already
been done: this is how Ad=C3=A9lie Linux operates. It would be a minimal
amount of effort to port this to Alpine.


>This is not an accurate characterization of events.  We have allowed indiv=
idual maintainers to use supervise-daemon in their packages for some time,=
 and have been migrating individual system services to supervise-daemon sinc=
e Jakub Jirutka began doing it in 2016.  This proposal is about finishing t=
hat migration -- which makes it easier for us to jump to another service ma=
nager later, as more initscripts are moved to declarative style.  Such a st=
ep would be necessary to adopt a new service manager, which may or may not=
 use s6.

  Again, I am not talking about adopting a new service manager, which is
indeed heavier work. I am talking about using s6 as a supervision suite
together with the OpenRC service manager. It's what I have been saying
from the start, but for some reason, it was never heard, and the
argument you are giving "we cannot replace the service manager at the
moment" is a strawman one. Yes, there is a s6-rc service manager and
I am working on a complete init sequence integration with friendlier
user commands, but this does not mean that you need the whole shebang
in order to use s6: s6 and OpenRC can work together in a satisfactory
way, as proven by Ad=C3=A9lie.


>We see s6 as a post-openrc option, because openrc already has a supervisor =
that is integrated into openrc, but we are not quite ready to make a jump=
 away from OpenRC yet.  Other initiatives, such as ifupdown-ng, are intended =
in part, to demonstrate the architecture we would want for a service manag=
er.

  What I am reading is "we don't want to mix-and-match software, so as
long as we're tied to OpenRC, we prefer using the supervision
implementation that they are providing". Which is a reasonable argument
that I can hear, but it is the first time you are making it, and I am
left wondering why nobody has made it since 2016, or why you are still
also answering with "we're not ready to switch service managers" which
is irrelevant for now.

  In any case, you've (finally) made it clear that a s6+OpenRC solution
is definitely not what you want, so I'll stop pushing, and keep working
on the integrated init system instead. It's coming along slowly, but not
any more slowly than the Alpine zeitgeist change, so it will be ready
in time. :P

--
  Laurent