El 20/07/21 a las 20:57, Thomas Goirand escribió: > On 7/19/21 3:07 PM, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers <elb...@debian.org> wrote: > >> Hi, > >> > >> On 12-07-2021 18:45, Michael Biebl wrote: > >>> This was already discussed in > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > >>> > >>> My takeaway from that discussion was, that rdeps of cgroup-tools, would > >>> itself have to be made cgroupv2 aware, especially OpenStack and its > >>> components. > >> > >> That resembles my understanding of that discussion too. > > > > Mine too. > > > > zigo, are there any news from openstack about this? > > There is no way that Cinder and Nova produce a patch for OpenStack > Victoria (the release in Bullseye), which was released 9 months ago. > They are *planning* to use Cgroups v2 right now, but I'm not even sure > it's going to be ready for next version in October. > > >>> Have those rdeps been tested successfully with libcgroup/cgroup-tools > >>> from experimental? > >> > >> I'm not in favor of doing this transition now. > >> > > > > Please, keep in mind this comment, made before the release of 2.0: > > "we are planning something for next week. The version number will > > probably be 2.0 - with expectation that the v2 cycle will have > > continously breaking ABI. When we are happy where it is, we will push > > out v3 which will then maintain ABI through its lifetime." > > https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 > > This means that probably, it's best that Bullseye continues to support > Cgroups v1 (which isn't the case currently if we don't allow libcgroup > 2.0 in).
I don't understand your sentences between parenthesis, sorry. What do you mean? > On 7/19/21 11:48 PM, Adrian Bunk wrote: > > Based on soname and package name, the libcgroup1 in experimental > > claims to be ABI compatible with the library in buster. > > Changes in bookworm would be a normal library transition. > > > > OpenStack uses cgroup-tools, which is the only reason why libcgroup > > stayed in bullseye at all. > > My suggestion was basically asking whether 2.0 would be better for > > using with the version of OpenStack in bullseye, this is similar to > > your question to Thomas above. > > > > If cgroup-tools in *bookworm* would be incompatible with OpenStack in > > bullseye, this could be resolved with Breaks on the bullseye versions > > of cinder-common/nova-compute - this is irrelevant for discussing > > which version of libcgroup to ship in bullseye. > > Maybe I'm not understanding fully, though what I think I've read in this > discussion, is that libcgroup in experimental makes it possible to use > cgcreate / cgset without any additional kernel command line parameters > (please let me know if I'm mistaking). That is partially true. Those kernel command lines parameters you are referring too enable cgroupv1 (from systemd, if I am not wrong) > On the OpenStack side, that's the > only thing which is needed. Not exactly. The file structure (and resources) differ between cgroupv1 and cgroupv2. One has a separate hierarchy of resources, the other has a unified hierarchy. See https://chrisdown.name/talks/cgroupv2/cgroupv2-fosdem.pdf I don't have my irc log here, but I think I already gave you an example of the changes needed. https://sources.debian.org/src/cinder/2:17.0.1-1/cinder/privsep/cgroup.py/?hl=28#L28 That blkio resource path from cgroupv1 is not supported in cgroupv2 and you have to replace it. For io.max, if I am not wrong. So your code also needs to know what version of control group is enabled to use the correct resource path. It shouldn't be a difficult patch, but someone has to do it, and test it. > Cinder isn't using any library directly, > they just use the cgroup userland binaries. As for Nova, I'm not even > sure it's doing anything but using features from Qemu/Libvirt (this > would have to be checked). At least, doing a "grep -r cgcreate" in the > Nova source code returns nothing. > > Cheers, > > Thomas Goirand (zigo)
