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 <bl...@debian.org> wrote: > On Wed, 19 Jul 2023 at 11:30, Lewis Gaul <lewis.g...@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 >
