Hi Luca,
> sufficient?
> 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@xxxxxxxxxx> wrote:
On Wed, 19 Jul 2023 at 11:30, Lewis Gaul <lewis.gaul@xxxxxxxxx> 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
