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 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)
Bug#990990: unblock: libcgroup/2.0
El 20/07/21 a las 00:48, Adrian Bunk escribió: > On Mon, Jul 19, 2021 at 03:07:49PM +0200, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers 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? > > > > > > > > > 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 > > What kind of ABI is this referring to? I am afraid I haven't found any details about this, or asked for them (yet). Sorry for my quick answer. I intended to say that we can't expect the v2 cycle to be stable. But that doesn't necessarily mean it couldn't get into a debian stable release. Sorry if this was just noise. > > 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. Indeed. > > 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. Yes. Again, sorry for introducing noise. Just for the record, cgroup-tools (e.g. cgcreate or any other tool) in bookworm won't (or shouldn't) be incompatible with OpenStack in bullseye, since those cgroup-tools support cgroupv1 and cgroupv2. But the rdeps *also need to support cgroupv2* to make use of the correct resource paths. It is useless to have libcgroup supporting cgroupv2 in bullseye if the rdeps are not aware of it. I'll give more details in my answer to Thomas. Cheers, -- Santiago
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 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)
Bug#990990: unblock: libcgroup/2.0
On Mon, Jul 19, 2021 at 03:07:49PM +0200, Santiago Ruano Rincón wrote: > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers 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? > > > > > > 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 What kind of ABI is this referring to? 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. > Cheers, > > -- Santiago cu Adrian
Bug#990990: unblock: libcgroup/2.0
On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers 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? > > > 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 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#990990: unblock: libcgroup/2.0
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. > Have those rdeps been tested successfully with libcgroup/cgroup-tools > from experimental? I'm not in favor of doing this transition now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990990: unblock: libcgroup/2.0
Hi Adrian Am 12.07.21 um 14:51 schrieb Adrian Bunk: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Background: https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html#openstack-cgroups https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022#66 I noticed a version of libcgroup with support for control groups v2 is now in experimental. Given then known problems with the libcgroup currently in bullseye (it only works when booting with special kernel parameters), this bug is a question to the release team and the OpenStack maintainer whether updating libcgroup in bullseye to the version currently in experimental might be the smaller evil compared to the current release notes approach. Complete diffstat compared to the version in testing: 223 files changed, 73421 insertions(+), 34626 deletions(-) Diff of debian/ is attached. The new version adds autopkgtests, but they aren't currently run: SKIP Test requires machine-level isolation but testbed does not provide that No new bugs are reported in the BTS. 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. Have those rdeps been tested successfully with libcgroup/cgroup-tools from experimental? Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#990990: unblock: libcgroup/2.0
On 7/12/21 2:51 PM, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Background: > https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html#openstack-cgroups > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022#66 > > I noticed a version of libcgroup with support for control groups v2 > is now in experimental. > > Given then known problems with the libcgroup currently in bullseye > (it only works when booting with special kernel parameters), > this bug is a question to the release team and the OpenStack > maintainer whether updating libcgroup in bullseye to the version > currently in experimental might be the smaller evil compared > to the current release notes approach. > > > Complete diffstat compared to the version in testing: > 223 files changed, 73421 insertions(+), 34626 deletions(-) > Diff of debian/ is attached. > > The new version adds autopkgtests, but they aren't currently run: > SKIP Test requires machine-level isolation but testbed does not provide that > > No new bugs are reported in the BTS. > > Tnd the debdiff of debian/ looks sane, except for a 12 -> 13 dh compat > bump that is revertable if requested. > > Both libcgroup1.symbols and abidiff of the shared library look sane. > > There are new libraries (libcgset and libcgroupfortesting) that are unused. > They lack .so symlinks in libcgroup-dev, which is an easily fixable bug. > > The only package currently linked with libcgroup1 in bullseye > is clsync (OpenStack uses cgroup-tools), debdiff and diffoscope > find no code changes when rebuilding with libcgroup from experimental. > Hi, I very much would prefer if libcgroup/2.0 could be in Bullseye, and avoid having to set these kernel parameters at boot time. It's even more annoying because Debian probably will be the only distro in the world to have the bad combination of component mandating these kernel parameters, making it the least convenient platform to run cgroups v1. So yeah, by all means, let's get things fixed! Cheers, Thomas Goirand (zigo)
Bug#990990: unblock: libcgroup/2.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Background: https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html#openstack-cgroups https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022#66 I noticed a version of libcgroup with support for control groups v2 is now in experimental. Given then known problems with the libcgroup currently in bullseye (it only works when booting with special kernel parameters), this bug is a question to the release team and the OpenStack maintainer whether updating libcgroup in bullseye to the version currently in experimental might be the smaller evil compared to the current release notes approach. Complete diffstat compared to the version in testing: 223 files changed, 73421 insertions(+), 34626 deletions(-) Diff of debian/ is attached. The new version adds autopkgtests, but they aren't currently run: SKIP Test requires machine-level isolation but testbed does not provide that No new bugs are reported in the BTS. Tnd the debdiff of debian/ looks sane, except for a 12 -> 13 dh compat bump that is revertable if requested. Both libcgroup1.symbols and abidiff of the shared library look sane. There are new libraries (libcgset and libcgroupfortesting) that are unused. They lack .so symlinks in libcgroup-dev, which is an easily fixable bug. The only package currently linked with libcgroup1 in bullseye is clsync (OpenStack uses cgroup-tools), debdiff and diffoscope find no code changes when rebuilding with libcgroup from experimental. diff -Nru libcgroup-0.41/debian/changelog libcgroup-2.0/debian/changelog --- libcgroup-0.41/debian/changelog 2021-02-08 15:43:56.0 +0200 +++ libcgroup-2.0/debian/changelog 2021-05-11 16:54:21.0 +0300 @@ -1,3 +1,36 @@ +libcgroup (2.0-1) experimental; urgency=medium + + * New upstream version 2.0 +- Fix cgroup-tools does not work in cgroup2 / unified hierarchy + (Closes: #959022) + * Add upstream signing key + * Update debian/watch to include matching signature + * Fix test-cgroupv1, set linux cmdline to support cgroupv1 + * Redirect update-grub stderr to stdout in d/test/tools-cgroupv1. Thanks to +Simon McVittie + * Add debian/tests/tools-cgroupv2 + * Update d/copyright to include googletest + * Update debian/libcgroup1.symbols + * Add Build-Depends-Package field to libcgroup1.symbols + + -- Santiago Ruano Rincón Tue, 11 May 2021 15:54:21 +0200 + +libcgroup (0.42.2-1) experimental; urgency=medium + + * Update d/watch to point to the new upstream at github + * New upstream version 0.42.2 + * Remove no longer needed debian/patches/CVE-2018-14348.patch + * Bump debhelper-compat to 13 + * Bump Standards-Version to 4.5.1. No changes required + * Install *.a files into libcgroup-dev + * d/rules: remove security/*.a to avoid --fail-missing error + * Add debian/salsa-ci.yml + * Add d/tests/tools-cgroupv1 + * Update debian/libcgroup1.symbols + * Adopt libcgroup (Closes: #823161) + + -- Santiago Ruano Rincón Tue, 13 Apr 2021 20:48:31 +0200 + libcgroup (0.41-11) unstable; urgency=medium * QA upload. diff -Nru libcgroup-0.41/debian/control libcgroup-2.0/debian/control --- libcgroup-0.41/debian/control 2021-02-08 15:43:56.0 +0200 +++ libcgroup-2.0/debian/control2021-04-13 22:51:58.0 +0300 @@ -1,14 +1,14 @@ Source: libcgroup Priority: optional Section: libs -Maintainer: Debian QA Group +Maintainer: Santiago Ruano Rincón Build-Depends: -debhelper-compat (= 12), +debhelper-compat (= 13), bison, flex, libpam-dev, Rules-Requires-Root: no -Standards-Version: 4.4.1 +Standards-Version: 4.5.1 Homepage: http://libcg.sourceforge.net/ Vcs-Git: https://salsa.debian.org/debian/libcgroup.git Vcs-Browser: https://salsa.debian.org/debian/libcgroup diff -Nru libcgroup-0.41/debian/copyright libcgroup-2.0/debian/copyright --- libcgroup-0.41/debian/copyright 2021-02-08 15:43:56.0 +0200 +++ libcgroup-2.0/debian/copyright 2021-04-30 16:30:55.0 +0300 @@ -13,6 +13,10 @@ 2008 Vivek Goyal License: BSD-3-clause or GPL-2, and LGPL-2.1 +Files: googletest/* +Copyright: 2008, Google Inc. +License: BSD-3-clause-google + Files: debian/* Copyright: 2009 Jon Bernard 2013-2014 Daniel Baumann @@ -46,6 +50,33 @@ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +License: BSD-3-clause-google + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are + met: + . + * Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above + copyright notice, this list of conditions and the following disclaimer + in the documentation and/or other materials
