On Fri, 15 Mar 2019 16:07:15 +0000 "Laurent Bercot" <[email protected]> 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 | [email protected] Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47
pgpMARBzbCxLt.pgp
Description: OpenPGP digital signature
