Open Stack

I can now confirm that
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
)

Best wishes.
     Neil


On Mon, Oct 4, 2021 at 6:28 PM Neil Jerram <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> 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
>>> [2]
>>>
>>> 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> 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
>>> >>
>>> >> 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/20211004/95cb1aeb/attachment-0001.htm>