Repository navigation
Proposal: synchronize cgroupv1 deprecation announcements #1251
Description
At a breakout session in Container Plumbing Days, @AkihiroSuda brought up the topic of a timeline to the cgroupv1 deprecation and removal. In discussing, we came up with a handful of ideas around it. I will begin by summarizing them. As a note: "we" in this conversation includes maintainers of OCI runtimes, and higher level container managers.
- Do we announce deprecation earlier than distros and the kernel (similar to how systemd did)?
- What are the steps that projects should take in announcing/dropping support
- Do we announce as a group?
There seemed to be consensus on the idea of having the OCI runtimes and managers make some sort of shared announcement on the intention of dropping cgroupv1 support. It doesn't require consensus on all implementations, but I think it would be most impactful if it was done together. Note: this conversation is tangential but related to a similar conversation happening in Kubernetes. in this conversation, we're focusing on lower levels, but the Kubernetes community could take a different timeline if they choose.
@AkihiroSuda suggested we open an issue here to announce follow-up conversations about it. @jberkus created a channel in the OCI slack to discuss further, but I'll let this be an entry point into that conversation. If you know of someone who may be interested in such a conversation, please tag them here or invite them to the slack channel (folks can join the OCI slack by following this link)
Activity
haircommander commentedon Apr 16, 2024
non-exhaustive list of folks who may be interested (please cc others who may be)
cri-o: @mrunalp @saschagrunert @sohankukerkar @kwilczynski
crun: @giuseppe
podman: @rhatdan @baude @mheon @umohnani8
AkihiroSuda commentedon Apr 16, 2024
Links to relevant discussions
(maintainers: feel free to edit this post)
AkihiroSuda commentedon Apr 16, 2024
cgroup v1 distros
I'd suggest keeping cgroup v1 until 2029 at least.
Can be 2030+ depending on the feedbacks from users.
utam0k commentedon Apr 16, 2024
👀 Thanks for giving us a forum to discuss this. First a brief comment, I agree with the direction towards v1 deprication as OCI Runtime maintainer and youki developer.
We will at least have to support it longer than Kubernetes.
For users who see this, supporting v1 means not only more development effort, but also that it will continue to be harder and harder to make new features introduced only in v2 (which will increase) available from containers.
mheon commentedon Apr 16, 2024
On the Podman side, we have already announced that cgv1 is deprecated as of our 5.0 upstream release, and we are actively warning users on v1 distros that support will be removed at a later date.
kannon92 commentedon Apr 18, 2024
RHEL 9.4 has deprecated cgroup v1 support.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/9.4_release_notes/deprecated-functionality
utam0k commentedon Apr 19, 2024
Just info: Kubernetes has changed the name of the issue to " Moving cgroup v1 support into maintenance mode Move cgroup v1 support into maintenance mode".
rata commentedon Mar 3, 2025
Big +1 to keep it working in OCI runtimes and use the "maintenance mode" or even "not even bug fixes" at some point in the future if needed, and we of course add things that only work in cgroups v2.
pacoxu commentedon Sep 28, 2025
Just for your information, kubernetes/enhancements#5573 is WIP to make cgroup v1 unsupported in kubelet.