Open Stack

On Thu, Oct 14, 2021 at 10:03 AM Előd Illés <elod.illes at est.tech> wrote:

> 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.
>

I don't know if someone was working on it already but I proposed the patch
on Ussuri: https://review.opendev.org/c/openstack/requirements/+/821878
If this gets accepted, I'll backport it to stable/train as well.

Without that patch, it's impossible to use Devstack outside of the gate to
deploy Ussuri or Train.

Thanks,

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 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>
>>> <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)
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>

-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211215/2dba01e1/attachment-0001.htm>