cinder doesnt work with cgroups v2

[Thomas Goirand]

Hi,

cgroups v2 has landed in Debian Unstable. Therefore, Cinder QoS with cgroups is now broken. Here's the matching Debian bug:

https://bugs.debian.org/993311

This likely will propagate to Ubuntu very quickly...

I'm hereby cut/pasting part of the Debian bug:

It means that instead of using blkio, as in https://sources.debian.org/src/cinder/2:18.0.0-2/cinder/privsep/cgroup.py/#L28 cinder has to use the io controller (If I am not wrong). You can refer to the kernel documentation about cgroups v2: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io

Cinder would have to call `cgset` and `cgcreate` with paths according to the cgroup version supported by the running system. To know if cgroup v2 is supported, one way is to `grep cgroup2 /proc/mounts`

I'm not really sure of what's just above though. If this checks if the kernel supports it, it doesn't tell what flavor of the cgroup userland is supported. Therefore, to play it self, I would suggest using a configuration value so that Cinder can:
- autodetect (attempt with how it's described above)
- force old style cgroup v1
- force new style cgroup v2

Cheers,

Thomas Goirand (zigo)

[Brian Rosmaita (brian-rosmaita)]

We're going on the assumption that everyone supports cgroup v2, and the issue is that they're dropping support for cgroup v1. So we should just switch to cgroup v2.

The other issue is that the library cinder uses to handle cgroup (v1), libcgroup, has been extended to handle cgroup v2, but it is not packaged for the Red Hat family of distros (and apparently there are no plans to do so).

The recommendation seems to be to use systemd to handle cgroup creation. For example, see https://www.suse.com/support/kb/doc/?id=000018890

Eric Harney suggests something like this: define systemd .slice files, and launch the command with "systemd-run --slice=cinder-whatever.slice <command>" instead of cgexec (cgexec is supplied by libcgroup).