Warn if cgroups-v1

[lsm5]

Podman v5 will not support cgroups-v1. This commit will print a warning if it detects a cgroups-v1 system.

Resolves: https://issues.redhat.com/browse/RUN-1957

Does this PR introduce a user-facing change?

cgroups-v1 is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Users on cgroups-v1 systems will see warnings to that effect and should consider switching to cgroups-v2.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dustymabe]

So will podman v5 user systems fail if on cgroups v1 OR will they just see this warning?

i.e. deprecated OR not supported at all ?

[rhatdan]

It is not supported. I believe. Not sure if this should warn or fail.

[dustymabe]

It is not supported. I believe. Not sure if this should warn or fail.

A better user experience would be for it to fail with a helpful error message rather than warn and then let things fail later with possibly unclear errors.

[lsm5]

It is not supported. I believe. Not sure if this should warn or fail.

A better user experience would be for it to fail with a helpful error message rather than warn and then let things fail later with possibly unclear errors.

@mheon wdyt?

[lsm5]

It is not supported. I believe. Not sure if this should warn or fail.

A better user experience would be for it to fail with a helpful error message rather than warn and then let things fail later with possibly unclear errors.

@dustymabe AFAIK, we need to support v1 on rhel9 for life, so this part will need to be patched out from the rhel9 rpms. I'm open to suggestions on how we deal with other environments.

[lsm5]

@dustymabe are there fcos or rhcos configs with cgroups-v1 still being supported, apart from rhel9-based ones? Asking because AFAIK, fedora is on v2 already so this change will have no effect. RHEL 10 will also be v2 AFAIK and on RHEL 9, this warning will be patched out at rpm build time. So, best I can tell, fedora / fcos and their downstreams / derivatives won't be affected with this change.

With this warning in place, users on other envs with v1 won't be broken right away and we can do the actual removal / failure in a later version. @mheon correct me if I'm wrong or forgetting anything from prior discussion.

[giuseppe]

we still need to keep the code around so IMO a warning is better. We don't break users stuck on cgroup v1 for any reason, and we can ignore cgroup v1 issues as the warning message is clear. Maybe we can just mention that it will be removed in future:

"WARNING! You are using cgroups v1 which is not supported on Podman v5 and will be removed in a future version. Consider switching to cgroups v2."

[lsm5]

we still need to keep the code around so IMO a warning is better. We don't break users stuck on cgroup v1 for any reason, and we can ignore cgroup v1 issues as the warning message is clear. Maybe we can just mention that it will be removed in future:

"WARNING! You are using cgroups v1 which is not supported on Podman v5 and will be removed in a future version. Consider switching to cgroups v2."

@giuseppe thanks updated.

I'd rather not change anything in the docs right now as rhel9 will still need cgroups-v1. I feel the warning and the RELEASE_NOTES update should suffice.

I'll update the rpm spec to patch out this warning in an additional commit.
EDIT: added rpm spec patch in the same commit so it's easier to revert with the main change.

[mheon]

Yeah, you captured the discussion @lsm5 - we can't entirely remove v1 support but we definitely want people to be aware they are using it (and also we want to make it very obvious in upstream bug reports so we can ask folks to move off deprecated code).

[lsm5]

@containers/podman-maintainers PTAL

[Luap99]

I would assume this needs some doc changes as well. The man page should state that it is not supported if we say this in the code.
Although I must say I find saying "not supported" extremely confusing the code clearly supports it today and it should work (I think). Wouldn't it be better to say it is deprecated in favor of v2?

[lsm5]

I would assume this needs some doc changes as well. The man page should state that it is not supported if we say this in the code. Although I must say I find saying "not supported" extremely confusing the code clearly supports it today and it should work (I think). Wouldn't it be better to say it is deprecated in favor of v2?

I'm fine with changing to deprecated in favor of v2 assuming everyone else is too.

[lsm5]

need to fix debian tests.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[edsantiago]

LGTM apart from the non-namespaced envariable. I won't block over that.

[lsm5]

LGTM apart from the non-namespaced envariable. I won't block over that.

Thanks. That was intentional cause we wanna do similar for buildah

[edsantiago]

Repeating my comment, which may have been missed:

I have pretty strong feelings about namespace pollution. Someone may add this to their rc files, then a year later have no recollection what it's for. May I encourage us all to rethink this? I would really prefer PODMAN_etc, BUILDAH_etc, SKOPEO_etc. It's more annoying but for something like this annoying is good.

[edsantiago]

Well, so much for that idea. I guess quadlet sends this to the container itself, and the podman command never sees it. Back to the drawing board.

[Luap99]

you would need to set the environment section under the systemd [Service] section not [Container] as this maps to --env which of course does not effect podman itself.

[lsm5]

Repeating my comment, which may have been missed:

I have pretty strong feelings about namespace pollution. Someone may add this to their rc files, then a year later have no recollection what it's for. May I encourage us all to rethink this? I would really prefer PODMAN_etc, BUILDAH_etc, SKOPEO_etc. It's more annoying but for something like this annoying is good.

alright, I can update the PR.

[edsantiago]

Please wait for a solution to the quadlet problem

[edsantiago]

Many rabbit holes later, I think the best solution is:

diff --git a/test/system/252-quadlet.bats b/test/system/252-quadlet.bats
index 5a4ecf775..69c55fb10 100644
--- a/test/system/252-quadlet.bats
+++ b/test/system/252-quadlet.bats
@@ -155,7 +155,7 @@ EOF
 
     # FIXME: Temporary until podman fully removes cgroupsv1 support; see #21431
     if [[ -n "$IGNORE_CGROUPSV1_WARNING" ]]; then
-        echo "Environment=IGNORE_CGROUPSV1_WARNING=1" >>$quadlet_file
+        skip "Way too complicated to test under cgroupsv1, and not worth the effort"
     fi
 
     run_quadlet "$quadlet_file"

[lsm5]

@ashley-cui @cevich mind checking out the machine-mac failure before I go rerunning it again?

[ashley-cui]

@lsm5 expected to fail for now, this should be good to go

[edsantiago]

/lgtm
/hold

[lsm5]

/hold cancel