After sleeping on this a bit, I think the expectation implicitly set out in the Change page that various container and virtualization tools will adapt to be compatible with v2 is unrealistic. To some extent this is like the python2→3 transition: stragglers will block the transition, and for each roadblock that is overcome, a new one will pop up, for years and years. In case of cgroups, the delay is not caused by some complex technological issues, but rather by lack of motivation and political discussions. Because of this, the ecosystem has been moving so extremely slowly, even though kernel and systemd support is there since a few years. I think we need to accept the fact that some things will not be ready for a while yet, and simply flip the default without blocking on them. People who need to run software that needs cgroups v1 should simply set the appropriate option on the kernel commandline. At least for a while, we'll try to keep the v1 compatibility going in other tools, in particular systemd.

+1, with the assumption that the contingency plan will not be invoked. (At least I'll vote against, if the issue is only that some leaf software doesn't work with v2.)

+1 (also agree with what @zbyszek said about contingency plan)

+1 to everything @zbyszek said (and to the Change)

snapd upstream has begun the initial work to support CGroups v2 in response to this change proposal: https://github.com/snapcore/snapd/pull/7109

I fully expect things will be working soon enough for snapd on a unified cgroups hierarchy.

I abstain.

A week has passed and this change has been APPROVED (+3,1,-0) with a modification of the contingency plan specified in https://pagure.io/fesco/issue/2177#comment-581761

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5VPN4DZ2SJ6IEK7SQWY4NVZTBPHFRPSX/