Changes/CGroupsV2

Modify Fedora 31 to use CgroupsV2 by default

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: Daniel J Walsh
• Email: <dwalsh@redhat.com>
• Release notes owner:

Current status

• Targeted release: [[Releases/<number> | Fedora 31 ]]
• Last updated: 2019-07-22
• Tracker bug: <will be assigned by the Wrangler>

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: https://bugzilla.redhat.com/show_bug.cgi?id=1438079

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

• Release engineering: #8509 (a check of an impact with Release Engineering is needed)
  • List of deliverables:

• Policies and guidelines:

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Upgraded machines will continue to work with CGroupsV1 unless the administrator changes the default. We need to document the change in order to allow administrators to convert their machines to take advantage of the new features.

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