Open Stack

I've pushed all the necessary changes for nova, neutron and swift [1]. 
Though as you say, we need to merge these in reverse order (from pike, 
till train), so it will take some time (even if we don't hit another 
gate breakage). Anyway, you are right that doing it in requirements 
repository would be quicker, but let's see first if we can start sorting 
this out without that.

Cheers,

Előd

[1] https://review.opendev.org/q/topic:bug%252F1907438

On 2020. 12. 10. 16:10, Lee Yarwood wrote:
> On 10-12-20 15:42:13, Bernard Cafarelli wrote:
>> On Wed, 9 Dec 2020 at 16:46, Lee Yarwood <lyarwood at redhat.com> wrote:
>>
>>> On 09-12-20 14:40:06, Jeremy Stanley wrote:
>>>> On 2020-12-09 13:59:04 +0000 (+0000), Lee Yarwood wrote:
>>>>> Hello all,
>>>>>
>>>>> $subject [1][2] is breaking various <= stable/train jobs where we
>>>>> attempt to pull bandit in while still using py2. This has been reported
>>>>> upstream and it looks like the 1.6.3 release may end up being yanked.
>>>>>
>>>>> If it isn't I've proposed the following requirements change to try to
>>>>> cap bandit to the 1.6.2 release, assuming this is safe to do on stable:
>>>>>
>>>>> Cap bandit at 1.6.2 when using py2
>>>>> https://review.opendev.org/c/openstack/requirements/+/766170
>>>> [...]
>>>>
>>>> It's typically recommended to pin static analysis tools strictly
>>>> less than the next major release in (test-)requirements lists of
>>>> individual projects. Part of why it's blacklisted in the global
>>>> requirements repository is so that the central upper-constraints.txt
>>>> won't override project level decisions on what versions of these
>>>> tools to run. Granted, it would also have made more sense if bandit
>>>> uprevved to 2.0.0 when dropping Python 2.x support, so that
>>>> in-project requirements in the form bandit<2 could have prevented
>>>> the impact. But all that's to say, pinning bandit in stable branches
>>>> of individual projects using it would be the more expected fix here.
>>> ACK thanks Jeremy, I had started that below before going back to an
>>> earlier attempt with requirements. I'll reopen these now and test things
>>> in the Nova change.
>>>
>>> https://review.opendev.org/q/topic:bug/1907438
>>>
>> This may get complicated to sort out, checking neutron cap [1], it failed
>> in grenade job when checking out bandit per swift requirements.
>> So it seems this one will need to be backported from the oldest affected
>> stable to train, with some "correct order" on packages - though if we need
>> it on 2 packages at same time to pass gates it may need overall capping?
>>
>> [1] https://review.opendev.org/c/openstack/neutron/+/766218
> Yeah indeed, Elod is going to try to land things in reverse from
> stable/pike under the above bug topic but even then we will need to
> force land changes across multiple projects for gates to work again.
>
> An overall cap landing in the same order from stable/pike forward to
> stable/train might be better approach.
>