<div dir="ltr"><div dir="ltr">On Wed, 9 Dec 2020 at 16:46, Lee Yarwood <<a href="mailto:lyarwood@redhat.com">lyarwood@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09-12-20 14:40:06, Jeremy Stanley wrote:<br>
> On 2020-12-09 13:59:04 +0000 (+0000), Lee Yarwood wrote:<br>
> > Hello all,<br>
> > <br>
> > $subject [1][2] is breaking various <= stable/train jobs where we<br>
> > attempt to pull bandit in while still using py2. This has been reported<br>
> > upstream and it looks like the 1.6.3 release may end up being yanked.<br>
> > <br>
> > If it isn't I've proposed the following requirements change to try to<br>
> > cap bandit to the 1.6.2 release, assuming this is safe to do on stable:<br>
> > <br>
> > Cap bandit at 1.6.2 when using py2<br>
> > <a href="https://review.opendev.org/c/openstack/requirements/+/766170" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/requirements/+/766170</a><br>
> [...]<br>
> <br>
> It's typically recommended to pin static analysis tools strictly<br>
> less than the next major release in (test-)requirements lists of<br>
> individual projects. Part of why it's blacklisted in the global<br>
> requirements repository is so that the central upper-constraints.txt<br>
> won't override project level decisions on what versions of these<br>
> tools to run. Granted, it would also have made more sense if bandit<br>
> uprevved to 2.0.0 when dropping Python 2.x support, so that<br>
> in-project requirements in the form bandit<2 could have prevented<br>
> the impact. But all that's to say, pinning bandit in stable branches<br>
> of individual projects using it would be the more expected fix here.<br>
<br>
ACK thanks Jeremy, I had started that below before going back to an<br>
earlier attempt with requirements. I'll reopen these now and test things<br>
in the Nova change.<br>
<br>
<a href="https://review.opendev.org/q/topic:bug/1907438" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:bug/1907438</a><br><br></blockquote><div>This may get complicated to sort out, checking neutron cap [1], it failed in grenade job when checking out bandit per swift requirements.</div><div>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?</div><div><br></div><div>[1] <a href="https://review.opendev.org/c/openstack/neutron/+/766218">https://review.opendev.org/c/openstack/neutron/+/766218</a></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Bernard Cafarelli<br></div></div></div>