DevHeads.net

Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

<a href="https://fedoraproject.org/wiki/Changes/CGroupsV2" title="https://fedoraproject.org/wiki/Changes/CGroupsV2">https://fedoraproject.org/wiki/Changes/CGroupsV2</a>

== Summary ==
The kernel has had some support for CgroupsV2 for some time, and yet
no one has used it because it is not on by default. There are lots of
new features and fixes over CgroupsV1 that it is time to reveal to the
user community.

== Owner ==
* Name: [[User:dwalsh| Daniel J Walsh]]
* Email: < ... at redhat dot com>

== Detailed Description ==
Enablement of the CgroupsV2 by default will allow tools like systemd,
container tools and libvirt to take advantage of the new features and
many fixes in Cgroups V1. A lot of the functionality in VGroups V1
has been rewritten to fix fundamental flaws in its design.

The reason CGroupsV2 by default has been blocked is that the Container
tools and someone the Virtualization tools did not have support. We
believe that the time is right to try to move these tools along to
take advantage of this kernel feature. In order to begin testing these
features more widely we believe we need to have a platform like
Rawhide to test on and get others to test as well.

The main features of CgroupsV2 we would like to take advantage of in
the container world is delegation of cgroup hierarchies. Allowing
tools like podman to be able to use CGroups in rootless mode, would be
a large advance.

== Benefit to Fedora ==
Fedora is known for being a leading platform for the enablement of new
kernel functions, and this would continue its legacy. The world will
eventually move to CGroupsV2 and Fedora should lead the way.

== Scope ==
* Proposal owners:
The largest changes required to make this Change is to get containers
runtimes like RUNC to work with the change. After RUNC has support
for CgroupsV2 we need to move container engines like Podman, CRI-o,
Buildah and Moby into support CgroupsV2.

* Other developers:
We need to find other tools that have built the CGroupsV1 API into
themselves and get them to support CGroupsV2.

Known packages:

- libvirt: The team is already working on this.

- JVM: Uses Cgroups file system to check for allocated memory for
the JVM, will have to use and understand the CgroupV2 mechanism to
discover these sessings.

- Snap package does not run with CGroupV2:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1438079" title="https://bugzilla.redhat.com/show_bug.cgi?id=1438079">https://bugzilla.redhat.com/show_bug.cgi?id=1438079</a>

- Systemd will need to be modified to set the new default to cgroupv2

* Release engineering: [https://pagure.io/releng/issue/8509 #8509]
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Any tools or scripts that an administrator used to manually configure
the CGroupsV1 will have to be modified to CGroupsV2. Luckily if these
tools took advantage of systemd interfaces they should not require
changes.

== How To Test ==
Make sure different tools that use cgroups continue to work when
booted into the new system. Make sure containers, virtual machines
and the Jave Virtual Machine still work properly. Convert the VM's of
the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
make sure their test suites completely pass. Will request that the
libvirt team and JVM teams similarly change their test platforms.

== User Experience ==
We believe that at this point their will be no or very little user
experience change, unless he is an administrator looking to modify the
system Cgroups using the cgroupsfs.

One potential problem will be container images that expect to be
running in a CgroupV1 environment. Some container engines leak the
Cgroup Hierarchy into containers so that tools within the container
can look at how much memory the cgroup gives them for example. These
tools might break with the change, but they should be adjusted quickly
over time, and I don't really see a way to avoid this.

== Dependencies ==
Currently there are no known changes to the package requirements for
this change.

== Contingency Plan ==
* Contingency mechanism: If the container tools and virtualization
tools do not work at beta and do not look like they will be ready for
beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
* Contingency deadline: Beta Freeze
* Blocks release? Yes

Comments

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to u

By Tomasz Torcz at 07/03/2019 - 16:34

On Wed, Jul 03, 2019 at 04:23:24PM -0400, Ben Cotton wrote:
What about Kubernetes? Will it work?
(Also upgrade would be nice, we ship 1.13 and latest is 1.15)