(CgroupV1 dependency within container images.) |
m (Fix release link) |
||
| (10 intermediate revisions by 5 users not shown) | |||
| Line 45: | Line 45: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/31| Fedora 31]] | ||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
| Line 55: | Line 55: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1732114 #1732114] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/361 #361] | |||
== Detailed Description == | == Detailed Description == | ||
| Line 106: | Line 107: | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
We need to find other tools that have built the CGroupsV1 API into themselves and get them to support CGroupsV2. | We need to find other tools that have built the CGroupsV1 API into themselves and get them to support CGroupsV2. | ||
| Line 112: | Line 112: | ||
Known packages: | Known packages: | ||
- libvirt: The team is already working on this. | - libvirt: The team is already working on this (DONE in libvirt 5.5.0) | ||
- 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. | - 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: <s>https://bugzilla.redhat.com/show_bug.cgi?id=1438079</s> (DONE) | |||
* Release engineering: [https://pagure.io/releng/ | - Systemd will need to be modified to set the new default to cgroupv2 (DONE in systemd-243~rc2-1.fc31) | ||
* Release engineering: [https://pagure.io/releng/issue/8509 #8509] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | |||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
| Line 131: | Line 134: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
Upgraded machines will continue to work with CGroupsV1 unless the administrator changes the default. | <strike>Upgraded machines will continue to work with CGroupsV1 unless the administrator changes the default.</strike> | ||
Upgraded machines will switch to the new default. Administrators who wish to retain the old default will need to set a kernel commandline option: `systemd.unified_cgroup_hierarchy=0`. | |||
We need to document the change in order to allow administrators to convert their machines to take advantage of the new features. | |||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 153: | Line 158: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Make sure different tools that use cgroups continue to work when booted into the new system. Make sure containers, virtual machines and the | Make sure different tools that use cgroups continue to work when booted into the new system. Make sure containers, virtual machines and the Java 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 == | == User Experience == | ||
| Line 159: | Line 164: | ||
--> | --> | ||
We believe that at this point their will be no or very little user experience change, unless | We believe that at this point their will be no or very little user experience change, unless the user 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. | 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. | ||
| Line 192: | Line 197: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF31]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 10:39, 13 February 2024
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: Fedora 31
- Last updated: 2024-02-13
- Tracker bug: #1732114
- Release notes tracker: #361
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 (DONE in libvirt 5.5.0)
- 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 (DONE)
- Systemd will need to be modified to set the new default to cgroupv2 (DONE in systemd-243~rc2-1.fc31)
- Release engineering: #8509 (a check of an impact with Release Engineering is needed)
- 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.
Upgraded machines will switch to the new default. Administrators who wish to retain the old default will need to set a kernel commandline option: systemd.unified_cgroup_hierarchy=0.
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 Java 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 the user 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