Open Stack

I completely agree with gibi:

- on master (and thus, stable/xena) we need to support the latest setuptools
- on older stable branches almost everything are already constrained 
(upper-constraints.txt), so I think that pinning setuptools on older 
branches is not that different than what we have now, plus it could 
eliminate a lot of possible similar issues in the future (I know, 
everything is 'temporary' as nothing will work forever, but if we want 
to make the stable maintenance easier then this is the better approach)

For me gibi's patch [1] looks quite promising for old stable branches. I 
know that it means that we have to create a similar patch for (at least) 
all broken old stable branches, but it unblocks the gate and seems quite 
trivial change.

Thanks,

Előd

[1] https://review.opendev.org/c/openstack/nova/+/810461


On 2021. 09. 22. 18:06, Balazs Gibizer wrote:
>
>
> On Wed, Sep 22 2021 at 08:39:03 AM -0700, Clark Boylan 
> <cboylan at sapwetik.org> wrote:
>> On Wed, Sep 22, 2021, at 5:11 AM, Balazs Gibizer wrote:
>>>  Hi,
>>>
>>
>> Snip
>>
>>>
>>>  The root of the problem is that we always use the latest setuptools in
>>>  our CI testing even on old stable branches. Zuul's ensure-tox task[4]
>>>  installs tox which installs the virtualenv package which bundles the
>>>  latest setuptools package. This happens without applying any
>>>  constraints. Then tox is used to install the project's dependencies
>>>  under lower or upper constraints with the unconstrained setuptools
>>>  available.
>>>
>>>  During and after yesterday's nova meeting [3] we discussed possible
>>>  solutions.
>>>
>>>  Option 1: Bump the major version of the decorator dependency on 
>>> stable.
>>>  Pros:
>>>  * easy to implement
>>>  Cons:
>>>  * might against the policy / breaks downstream packagers
>>>  * needs to be done in each affected project[3] separately
>>>  * not future proof. After a future setuptools release we can see a
>>>  similar break with another of our dependencies.
>>>
>>>  @Stable Cores: how do you feel about such bump?
>>>
>>>
>>>  Option 2: Pin the setuptools version during tox installation
>>>  Pros:
>>>  * single solution for all affected projects
>>>  * future proof against breaks introduced by future setuptools releases
>>>  Cons:
>>>  * complex change as it probably requires to extend the base task in
>>>  zuul itself
>>
>> Note as mentioned during the meeting yesterday I believe you actually 
>> need to pin virtualenv during the tox installation. If you want to 
>> pin setuptools it needs to happen when tox creates its virtualenvs.
>
> good point
>
>>
>> One major con to this approach is now you've stopped testing that 
>> your software can deploy with newer versions of setuptools. It 
>> doesn't work right this moment, but as circumstances change you'll be 
>> without up to date information.
>
> I agree not to pin this on master. We need to support the latest and 
> greatest on master. But on stable I don't see the problem saying we 
> only support the tooling version that was the latest when the major 
> release was created.
>
>>
>>>
>>>
>>>  Option 3: turn off lower-constraints testing
>>>  Pros:
>>>  * easy to implement
>>>  * some of us want to get rid of lower constraints anyhow
>>>  Cons:
>>>  * needs per project changes
>>>  * not future proof against similar break affecting our upper
>>>  constraints on old stable branches.
>>>
>>>
>>>  Option 4: utilize pyproject.toml[6] to specify build-time requirements
>>>  Unfortunately, I'm not sure if it is possible to restrict the maximum
>>>  setuptools version with it
>>>
>>>
>>>  As a side note I tried applying [tox]requires in tox.ini to restrict
>>>  setuptools version[7] but It does not seem to take effect in our
>>>  case[8].
>>
>> This didn't work because the requires specification seems to only 
>> affect the meta venv that tox uses to bootstrap itself if necessary 
>> [9]. Basically this pinned setuptools in the wrong virtualenv. This 
>> might work if you pinned virtualenv here as suggested above.
>
> Thanks for the pointers. I think I managed to make this work locally. 
> We will see if it works in CI too when [1] goes through the check 
> pipeline.
>
> Cheers,
> gibi
>
> [1] https://review.opendev.org/c/openstack/nova/+/810461
>
>
>