Bug#990990: unblock: libcgroup/2.0
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 <elbrus@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)
Reply to: