[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: https://review.opendev.org/#/c/658857/
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
>> https://review.opendev.org/#/q/topic:cap-bandit (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.