On Fri, 15 Mar 2019 16:07:15 +0000
"Laurent Bercot" <ska-skaware_at_skarnet.org> wrote:
> It is exceedingly difficult to use a distribution using systemd as
> its init system and entirely rip out systemd. It is quite possible
> to use s6 as the sole init system (and couple it with any service
> manager you want, be it s6-rc, anopa, slew, OpenRC...), but to
> achieve that, it's much easier to start from a distribution that does
> *not* use systemd. (Adélie, Alpine, Void, Gentoo, to name a few.)
Our view is, that using an non-mainstream distribution is a lot of work
for our purpose of being an PaaS provider. That would in the end mean
packaging a lot of services on our own.
Today the mainstream distribution doesn't package anymore all needed
services in the needed versions. In practice a lot of upstreams package
their stuff on their own or some people do it in ubuntu's PPA.
Because those upstreams/poeple can't handle full range support for all
linux distributions, you find the big 3 distributions:
- Debian
- Ubuntu
- Redhat/CentOS
Sometimes Fedora and SuSE. That's it.
It's very unlikely that we can takeover the job of creating packages
and in my opinion a lot of people are in a similar situation (IaaS
Provider, Webhosting Provider, SaaS Provider).
So they have to use mainstream distributions.
> If your goal is to be able to use Ubuntu packages out of the box,
> then you'll definitely be better off keeping the systemd ecosystem,
> which said packages could depend upon, and simply use s6 on top of
> it (s6-svscan being supervised by systemd).
If you mean "keep it installed": yes, definitly. For container based
systems, the one shot problem of system initialization is in practice
non-existent. So we tend to avoid running systemd as PID 1, even if
it's installed.
For VM based or bare metal based systems, there is a lot of one shot
jobs to do, loading drivers, mounting filesystems, decrypt block
devices, scan for logical volumes, attach iSCSI, whatever.
Writing units for that from scratch for everything is a big mess. So
without an portable approach of this (means at least portable for linux
distributions) I don't believe in a big success of a s6 one shot
implementation, which offers a full range of use cases - because it's
impossible to manage the effort of writing all this stuff.
For corner cases it might be successful, if you just want to support a
few setups. This might be true for us, even if we're not sure about
that.
> It is also possible to keep systemd but reduce its impact, by moving
> the boot services from systemd to a service manager running under s6,
> one by one. This can be a way to incrementally transition from a
> systemd-managed machine to a fully s6-managed machine.
I understand that approach and we tend to go that way for some
scenarios (VM, bare metal). For containers it's not a big deal to
remove systemd at all.
> There is a s6-frontend project in the making, which is planned to
> be released in 2020 or 2021 (could be much earlier if I got a
> sponsor and didn't have to work on unrelated contracts), which aims
> to offer a fully integrated init system and interface around the s6
> ecosystem (s6, s6-rc, s6-linux-init) including certain policy
> decisions: the goal is to make it easier for mainstream distributions
> to adopt s6 as a full-featured alternative to systemd. In the
> meantime, I am aware that lack of presence and support in mainstream
> projects is a major pain point for s6; but you can always write here,
> or to the list's sibling, the supervision mailing-list, and our
> small but vibrant community will certainly have insights to share.
Ok, I was wondering, where this frontend is. ;-) Good to know, that
there are plans around. We would like to support the s6 project. Today
we implement it on our side to see how good it is and will later decide
if we can keep it for production.
> For informal discussions that don't need a written record, there is
> also the #s6 channel on Freenode, where we're usually pretty
> reactive.
Thanks for the hint.
Best Regards
Oli
--
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz
www.automatic-server.com | oliver.schad_at_automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47
Received on Fri Mar 15 2019 - 23:19:21 UTC