Bug#990990: unblock: libcgroup/2.0
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).
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). On the OpenStack side, that's the
only thing which is needed. 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: