Open Stack

Hi,

First, sorry for the slow response.

I think pinning setuptools in requirements for stable branches is also a 
good idea (up till wallaby). I can accept that.

Another thing is that the openstack projects that I've checked don't 
have issues in their CI regarding the unpinned setuptools. Mostly I 
saw/see the problem in unit test, static code check and similar tox targets.

Anyway, if this issue is there for devstack for others then I think we 
can cap setuptools, too, in requirements repository, if it is OK for 
everyone. My only concern is to cap it from the newest relevant stable 
branch where we need it. If I'm not mistaken most of the projects have 
fixed their related issue in Xena, so I guess Wallaby should be the 
first branch to cap setuptools.

Thanks,

Előd


On 2021. 10. 04. 20:16, Neil Jerram wrote:
> I can now confirm that 
> https://review.opendev.org/c/openstack/requirements/+/810859 
> <https://review.opendev.org/c/openstack/requirements/+/810859> fixes 
> my CI use case.  (By temporarily using a fork of the requirements repo 
> that includes that change.)
>
> (Fix detail if needed here: 
> https://github.com/projectcalico/networking-calico/pull/64/commits/cbed6282405957f7d60b6e0790c91fb852afe84c 
> <https://github.com/projectcalico/networking-calico/pull/64/commits/cbed6282405957f7d60b6e0790c91fb852afe84c>)
>
> Best wishes.
>      Neil
>
>
> On Mon, Oct 4, 2021 at 6:28 PM Neil Jerram <neil at tigera.io 
> <mailto:neil at tigera.io>> wrote:
>
>     Is anyone helping to progress this?  I just checked that
>     stable/ussuri devstack is still broken.
>
>     Best wishes,
>         Neil
>
>
>     On Tue, Sep 28, 2021 at 9:20 AM Neil Jerram <neil at tigera.io
>     <mailto:neil at tigera.io>> wrote:
>
>         But I don't think that solution works for devstack, does it? 
>         Is there a way to pin setuptools in a stable/ussuri devstack
>         run, except by changing the stable branch of the requirements
>         project?
>
>
>         On Mon, Sep 27, 2021 at 7:50 PM Előd Illés
>         <elod.illes at est.tech> wrote:
>
>             Hi again,
>
>             as I see there is no objection yet about using gibi's
>             solution [1] (as I
>             already summarized the situation in my previous mail [2])
>             for a fix for
>             similar cases, so with a general stable core hat on, I
>             *suggest*
>             everyone to use that solution to pin the setuptools in tox
>             for every
>             failing cases (so that to avoid similar future errors as
>             well).
>
>             [1] https://review.opendev.org/810461
>             <https://review.opendev.org/810461>
>             [2]
>             http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025059.html
>             <http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025059.html>
>
>             Előd
>
>
>             On 2021. 09. 27. 14:47, Balazs Gibizer wrote:
>             >
>             >
>             > On Fri, Sep 24 2021 at 10:21:33 PM +0200, Thomas Goirand
>             > <zigo at debian.org <mailto:zigo at debian.org>> wrote:
>             >> Hi Gibi!
>             >>
>             >> Thanks for bringing this up.
>             >>
>             >> As a distro package maintainer, here's my view.
>             >>
>             >> On 9/22/21 2:11 PM, Balazs Gibizer wrote:
>             >>>  Option 1: Bump the major version of the decorator
>             dependency on
>             >>> stable.
>             >>
>             >> Decorator 4.0.11 is even in Debian Stretch (currently
>             oldoldstable), for
>             >> which I don't even maintain OpenStack anymore (that's
>             OpenStack
>             >> Newton...). So I don't see how switching to decorator
>             4.0.0 is a
>             >> problem, and I don't understand how OpenStack could be
>             using 3.4.0 which
>             >> is in Jessie (ie: 6 years old Debian release).
>             >>
>             >> PyPi says Decorator 3.4.0 is from 2012:
>             >> https://pypi.org/project/decorator/#history
>             <https://pypi.org/project/decorator/#history>
>             >>
>             >> Do you have your release numbers correct? If so, then
>             switching to
>             >> Decorator 4.4.2 (available in Debian Bullseye (shipped
>             with Victoria)
>             >> and Ubuntu >=Focal) looks like reasonable to me...
>             Sticking with 3.4.0
>             >> feels a bit crazy (and I wasn't aware of it).
>             >
>             > Thanks for the info. So from Debian perspective it is OK
>             to bump the
>             > decorator version on stable. As others noted in this
>             thread it seems
>             > to be more than just decorator that broke. :/
>             >
>             >>
>             >>>  Option 2: Pin the setuptools version during tox
>             installation
>             >>
>             >> Please don't do this for the master branch, we need
>             OpenStack to stay
>             >> current with setuptools (yeah, even if this means
>             breaking changes...).
>             >
>             > I've no intention to pin it on master. Master needs to
>             work with the
>             > latest and greatest. Also on master it is easier to fix
>             / replace the
>             > dependencies that become broken with new setuptools.
>             >
>             >>
>             >> For already released OpenStack: I don't mind much if
>             this is done (I
>             >> could backport fixes if something breaks).
>             >
>             > ack
>             >
>             >>
>             >>>  Option 3: turn off lower-constraints testing
>             >>
>             >> I already expressed myself about this: this is
>             dangerous as distros rely
>             >> on it for setting lower bounds as low as possible
>             (which is always
>             >> preferred from a distro point of view).
>             >>
>             >>>  Option 4: utilize pyproject.toml[6] to specify
>             build-time requirements
>             >>
>             >> I don't know about pyproject.toml.
>             >>
>             >> Just my 2 cents, hoping it's useful,
>             >
>             > Thanks!
>             >
>             > Cheers,
>             > gibi
>             >
>             >> Cheers,
>             >>
>             >> Thomas Goirand (zigo)
>             >>
>             >
>             >
>             >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211014/84b57c57/attachment-0001.htm>