[systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Lewis Gaul]

Hi Luca,

> All the distributions you quoted above support cgroupv2 to the best of
> my knowledge, it simply has to be enabled at boot. Why isn't that
> sufficient?

As I said in my previous email:

> in the case of it being a systemd container on an arbitrary host then a
lack of cgroup v1 support from systemd would place a cgroup v2 requirement
on the host, which is an undesirable property of a container.

and

> we are not in a position to require the end-user to reconfigure their
host to enable running our container.

Regards,
Lewis

On Wed, 19 Jul 2023 at 11:35, Luca Boccassi <bluca at debian.org> wrote:

> On Wed, 19 Jul 2023 at 11:30, Lewis Gaul <lewis.gaul at gmail.com> wrote:
> >
> > Hi Lennart, all,
> >
> > TL;DR: A container making use of cgroup controllers must use the same
> cgroup version as the host, and in the case of it being a systemd container
> on an arbitrary host then a lack of cgroup v1 support from systemd would
> place a cgroup v2 requirement on the host, which is an undesirable property
> of a container.
> >
> > I can totally understand the desire to simplify the codebase/support
> matrix, and appreciate this response is coming quite late (almost a year
> since cgroups v1 was noted as a future deprecation in systemd). However, I
> wanted to share a use-case/argument for keeping cgroups v1 support a little
> longer in case it may impact the decision at all.
> >
> > At my $work we provide a container image to customers, where the
> container runs using systemd as the init system. The end-user has some
> freedom on how/where to run this container, e.g. using docker/podman on a
> host of their choice, or in Kubernetes (e.g. EKS in AWS).
> >
> > Of course there are bounds on what we officially support, but generally
> we would like to support recent LTS releases of major distros, currently
> including Ubuntu 20.04, Ubuntu 22.04, RHEL 8, RHEL 9, Amazon Linux 2 (EKS
> doesn’t yet support Amazon Linux 2023). Of these, only Ubuntu 22.04 and
> RHEL 9 have switched to using cgroups v2 by default, and we are not in a
> position to require the end-user to reconfigure their host to enable
> running our container. What’s more, since we make use of cgroup controllers
> inside the container, we cannot have cgroup v1 controllers enabled on the
> host while attempting to use cgroups v2 inside the container.
> >
> > > Because of that I see no reason why old systemd cgroupv1 payloads
> > > shouldn#t just work on cgroupv2 hosts: as long as you give them a
> > > pre-set-up cgroupv1 environemnt, and nothing stops you from doing
> > > that. In fact, this is something we even documented somewhere: what to
> > > do if the host only does a subset of the cgroup stuff you want, and
> > > what you have to do to set up the other stuff (i.e. if host doesn't
> > > manage your hierarchy of choice, but only others, just follow the same
> > > structure in the other hierarchy, and clean up after yourself). This
> > > is what nspawn does: if host is cgroupv2 only it will set up
> > > name=systemd hierarchy in cgroupv1 itself, and pass that to the
> > > container.
> >
> > I don't think this works for us since we need the full cgroup (v1/v2)
> filesystem available in the container, with controllers enabled.
> >
> > This means that we must, for now, continue to support cgroups v1 in our
> container image. If systemd were to drop support for cgroups v1 then we may
> find ourselves in an awkward position of not being able to upgrade to this
> new systemd version, or be forced to pass this restriction on to end-users.
> The reason we’re uncomfortable about insisting on the use of cgroups v2 is
> that as a container app we ideally wouldn’t place such requirements on the
> host.
> >
> > So, while it's true that the container ecosystem does now largely
> support cgroups v2, there is still an aspect of caring about what the host
> is running, which from our perspective this should be assumed to be the
> default configuration for the chosen distro. With this in mind, we’d
> ideally like to have systemd support cgroups v1 a little longer than the
> end of this year.
> >
> > Does this make sense as a use-case and motivation for wanting new
> systemd versions to continue supporting cgroups v1? Of course not forever,
> but until there are less hosts out there using cgroups v1.
>
> All the distributions you quoted above support cgroupv2 to the best of
> my knowledge, it simply has to be enabled at boot. Why isn't that
> sufficient?
>
> Kind regards,
> Luca Boccassi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230719/2d5d5d1a/attachment.htm>