Open Stack

On 10-12-20 15:10:40, 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.

That said it looks like bandit 1.6.3 might be yanked and replaced by a
non-universal 1.6.4 release that might resolve this issue for us:

https://github.com/PyCQA/bandit/issues/663

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76