supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Dreamcat4 <dreamcat4@gmail.com>
To: Oliver Schad <oliver.schad@automatic-server.com>
Cc: supervision@list.skarnet.org
Subject: Re: s6 in production on Ubuntu - yeah!
Date: Wed, 4 Nov 2020 11:15:34 +0000	[thread overview]
Message-ID: <CAN39uTpvRKOcWevkkRc2Xs=kW+cP-y20mC-0XBC_TTU3b0=gbw@mail.gmail.com> (raw)
In-Reply-To: <20201104120111.7d950a36@flunder>

Yep. Have been using s6-overlay inside docker containers. On top of
the ubuntu 20.04 base image. It works well enough...

Perhaps you could speak to some Canonical people about your usage of
s6? Maybe it would be helpful to them, in some broader sense? Like to
be a little bit less reliant upon systemd?

On Wed, Nov 4, 2020 at 11:01 AM Oliver Schad
<oliver.schad@automatic-server.com> wrote:
>
> Hi everybody,
>
> we're proud to announce, that we have s6 in production in context of
> platform as a service for our customers.
>
> We started with the rollout on our container hypervisors and will
> extend that to all of our LXC containers.
>
> We use Ubuntu 16 for now and will migrate that to Ubuntu 20. The reasons
> we use that distro is, are some:
>
> - good package support from community
> - canonical maintains LXC/LXD
> - co-maintainers of ZFS
>
> So these are important reasons for us to stay on Ubuntu.
>
> Thanks Laurent for supporting us to develop the integration of s6 in
> ubuntu 16 and 20. We can definitly recommend to engage Laurent for
> integration questions.
>
> The reasons to migrate away from systemd are well known but to recap
> that in short:
>
> - buggy
> - bad support from development team (go-away mentality)
> - over complex in every dimension
> - really limited cause of DSL/config approach and really big config
>   language at the same time - more than 200 config statements - have
>   fun to know them all
> - tries to enforce itself everywhere as dependency
> - linux only
> - tightly bundled to kernel interfaces, which might be dangerous in
>   container business (container's systemd might depend on specific
>   kernel interfaces of the host)
> - cgroup massacre (mi-mi-mi that is my cgroup and nobody else is
>   allowed to use it)
>
> And I guess some more. The pain we had with systemd, journald and so on
> was too much.
>
> Best Regards
> Oli
>
> --
> Automatic-Server AG •••••
> Oliver Schad
> Geschäftsführer
> Turnerstrasse 2
> 9000 St. Gallen | Schweiz
>
> www.automatic-server.com | oliver.schad@automatic-server.com
> Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

  reply	other threads:[~2020-11-04 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-04 11:01 Oliver Schad
2020-11-04 11:15 ` Dreamcat4 [this message]
2020-11-04 17:37 ` Steve Litt
2020-11-04 17:37 ` Laurent Bercot
2020-11-04 17:38 ` Steve Litt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN39uTpvRKOcWevkkRc2Xs=kW+cP-y20mC-0XBC_TTU3b0=gbw@mail.gmail.com' \
    --to=dreamcat4@gmail.com \
    --cc=oliver.schad@automatic-server.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).