[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[oslo][requirements] Bandit Strategy

On 13/05/19 1:40 PM, Ben Nemec wrote:
> On 5/13/19 12:23 PM, Ben Nemec wrote:
>> Nefarious cap bandits are running amok in the OpenStack community! 
>> Won't someone take a stand against these villainous headwear thieves?!
>> Oh, sorry, just pasted the elevator pitch for my new novel. ;-)
>> Actually, this email is to summarize the plan we came up with in the 
>> Oslo meeting this morning. Since we have a bunch of projects affected 
>> by the Bandit breakage I wanted to make sure we had a common fix so we 
>> don't have a bunch of slightly different approaches in each project. 
>> The plan we agreed on in the meeting was to push a two patch series to 
>> each repo - one to cap bandit <1.6.0 and one to uncap it with a 
>> !=1.6.0 exclusion. The first should be merged immediately to unblock 
>> ci, and the latter can be rechecked once bandit 1.6.1 releases to 
>> verify that it fixes the problem for us.

I take it that just blocking 1.6.0 in global-requirements isn't an 
option? (Would it not work, or just break every project's requirements 
job? I could live with the latter since they're broken anyway because of 
the sphinx issue below...)

> Oh, and since sphinx is also breaking the Oslo world, I guess we're 
> going to have to include the sphinx requirements fix in these first 
> patches:

It's breaking the whole world and I'm actually not sure there's a good 
reason for it. Who cares if sphinx 2.0 doesn't run on Python 2.7 when we 
set and achieved a goal in Stein to only run docs jobs under Python 3? 
It's unavoidable for stable/rocky and earlier but it seems like the pain 
on master is not necessary.

> That's passing the requirements job so it should unblock us.
> /me is off to squash some patches
>> We chose this approach instead of just tweaking the exclusion in 
>> tox.ini because it's not clear that the current behavior will continue 
>> once Bandit fixes the bug. Assuming they restore the old behavior, 
>> this should require the least churn in our repos and means we're still 
>> compatible with older versions that people may already have installed.
>> I started pushing patches under 
>> (which prompted the 
>> digression to start this email ;-) to implement this plan. This is 
>> mostly intended to be informational, but if you have any concerns with 
>> the plan above please do let us know immediately.
>> Thanks.
>> -Ben