-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: synchronize cgroupv1 deprecation announcements #1251
Comments
non-exhaustive list of folks who may be interested (please cc others who may be) |
Links to relevant discussions(maintainers: feel free to edit this post)
|
cgroup v1 distros
I'd suggest keeping cgroup v1 until 2029 at least. |
👀 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. 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. |
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. |
RHEL 9.4 has deprecated cgroup v1 support.
|
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". |
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.
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)
The text was updated successfully, but these errors were encountered: