Speaker
Description
Enterprise users are likely one of the last holdovers still running cgroup
v1. As they continue to transition to cgroup v2, we would like to discuss
the deprecation (and potentially deletion) of cgroup v1.
In 2022 [1], systemd proposed the removal of cgroup v1 support from systemd,
but the community wasn't (yet) ready.
Work has already begun in the kernel to isolate cgroup v1 [2] in the memory
subsystem.
We would like to have an open forum to discuss the deprecation of cgroup v1
from all of Linux. Applications can't make these decisions in a vacuum
because there are so many interdependencies. The Containers and
Checkpoint/Restore LPC microconference may have the greatest representation
of the various interested parties, and we would like to leverage this to start
the discussion.
Areas of discussion:
* Is there any plan to isolate the cgroup v1 code in other controllers
(similar to the work that was done for the memory controller)
* What applications don't support cgroup v2? How do we get them there?
* Previously, v2 containers on a v1 host (or vice versa) was a point of
contention. Does this issue go away as older distros reach EOL?
* RHEL7 (cgroup v1) has reached EOL in summer of 2024
* Oracle Linux (OL) 7 (cgroup v1) reaches EOL in December of 2024
* Note that OL8 still defaults to cgroup v1 and its EOL is 2029 :(
* I'm afraid of the "unknown unknown" dependencies and interactions.
Is there anything we can do to plan and prepare for these?
* Can we come up with a roadmap or timeline for EOL'ing cgroup v1 across the
board?
We plan on bringing a list of distros, kernels, applications and their cgroup versions and EOL dates.
[1] https://lists.freedesktop.org/archives/systemd-devel/2022-July/048120.html
[2] https://lore.kernel.org/all/20240625005906.106920-1-roman.gushchin@linux.dev/