[all][stable] bandit 1.6.3 drops py2 support
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 Cheers, [1] https://github.com/PyCQA/bandit/releases/tag/1.6.3 [2] https://github.com/PyCQA/bandit/pull/615 [3] https://github.com/PyCQA/bandit/issues/663 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
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. -- Jeremy Stanley
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 Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On Wed, 9 Dec 2020 at 16:46, Lee Yarwood <lyarwood@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 -- Bernard Cafarelli
On 10-12-20 15:42:13, Bernard Cafarelli wrote:
On Wed, 9 Dec 2020 at 16:46, Lee Yarwood <lyarwood@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.
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?
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. -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
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@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.
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?
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
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@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.
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.
On 2020-12-10 15:42:13 +0100 (+0100), Bernard Cafarelli wrote: [...]
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?
Oh wow, this is the first I've realized devstack installed test-requirements.txt for every project. That's a total mess since projects are totally encouraged to use different versions of test requirements where things like linters and static analyzers are concerned. Can't https://review.opendev.org/715469 be backported? -- Jeremy Stanley
That patch looks promising! Thanks Jeremy! We need to be careful though as that could involve some new errors. I've found this mail [1] related to the mentioned patch with some errors and fixes. If that's all, then maybe that is the best way forward to backport these changes. @QA Team, what do you think? Are you aware of other possible issues? Thanks, Előd [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013681.htm... On 2020. 12. 10. 18:04, Jeremy Stanley wrote:
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 Oh wow, this is the first I've realized devstack installed test-requirements.txt for every project. That's a total mess since
On 2020-12-10 15:42:13 +0100 (+0100), Bernard Cafarelli wrote: [...] projects are totally encouraged to use different versions of test requirements where things like linters and static analyzers are concerned. Can't https://review.opendev.org/715469 be backported?
On Thu, 2020-12-10 at 17:04 +0000, Jeremy Stanley wrote:
On 2020-12-10 15:42:13 +0100 (+0100), Bernard Cafarelli wrote: [...]
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?
Oh wow, this is the first I've realized devstack installed test-requirements.txt for every project.
yep i have tried to stop it doing that a few times but apparently some project rely on that which causes issue. eventually https://review.opendev.org/c/openstack/devstack/+/715469/ did make that change and where we can backport it i would be in favor of that but this is not the first time that installing test requiremetn has broken dpeloyment due to linters. in partical it has broken the compliation of dpdk and ovs where the default linter configruution broke make sicne it ran the test and style check failed.
That's a total mess since projects are totally encouraged to use different versions of test requirements where things like linters and static analyzers are concerned. Can't https://review.opendev.org/715469 be backported?
On Thu, 2020-12-10 at 18:41 +0000, Sean Mooney wrote:
On Thu, 2020-12-10 at 17:04 +0000, Jeremy Stanley wrote:
On 2020-12-10 15:42:13 +0100 (+0100), Bernard Cafarelli wrote: [...]
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?
Oh wow, this is the first I've realized devstack installed test-requirements.txt for every project.
yep i have tried to stop it doing that a few times but apparently some project rely on that which causes issue. eventually https://review.opendev.org/c/openstack/devstack/+/715469/ did make that change and where we can backport it i would be in favor of that but this is not the first time that installing test requiremetn has broken dpeloyment due to linters. in partical it has broken the compliation of dpdk and ovs where the default linter configruution broke make sicne it ran the test and style check failed. https://review.opendev.org/c/openstack/nova/+/445622 is what i was refering too. when we added flake8-import-order to novas test-requiremtns.txt it broke networking-ovs-dpdk and would have broken the neutorn ovn jobs if they exsited at that time. this broke compliation of ovs as they dont enforce the same import ordering and this cause the build test to then fail.
That's a total mess since projects are totally encouraged to use different versions of test requirements where things like linters and static analyzers are concerned. Can't https://review.opendev.org/715469 be backported?
On 2020-12-10 18:41:04 +0000 (+0000), Sean Mooney wrote: [...]
yep i have tried to stop it doing that a few times but apparently some project rely on that which causes issue. eventually https://review.opendev.org/c/openstack/devstack/+/715469/ did make that change and where we can backport it i would be in favor of that but this is not the first time that installing test requiremetn has broken dpeloyment due to linters. in partical it has broken the compliation of dpdk and ovs where the default linter configruution broke make sicne it ran the test and style check failed. [...]
Maybe an alternative would be to have DevStack reuse the filter from openstack/requirements which is what we use to prevent including these tools in the upper-constraints.txt set? -- Jeremy Stanley
On 10-12-20 18:41:04, Sean Mooney wrote:
On Thu, 2020-12-10 at 17:04 +0000, Jeremy Stanley wrote:
On 2020-12-10 15:42:13 +0100 (+0100), Bernard Cafarelli wrote: [...]
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?
Oh wow, this is the first I've realized devstack installed test-requirements.txt for every project.
yep i have tried to stop it doing that a few times but apparently some project rely on that which causes issue. eventually https://review.opendev.org/c/openstack/devstack/+/715469/ did make that change and where we can backport it i would be in favor of that but this is not the first time that installing test requiremetn has broken dpeloyment due to linters. in partical it has broken the compliation of dpdk and ovs where the default linter configruution broke make sicne it ran the test and style check failed.
That's a total mess since projects are totally encouraged to use different versions of test requirements where things like linters and static analyzers are concerned. Can't https://review.opendev.org/715469 be backported?
Thanks for the pointer Jeremy! I've started that below, we will need to land this in reverse from stable/pike however to appease the grenade jobs: https://review.opendev.org/q/I8f24b839bf42e2fb9803dc7df3a30ae20cf264eb Cheers -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
participants (5)
-
Bernard Cafarelli
-
Előd Illés
-
Jeremy Stanley
-
Lee Yarwood
-
Sean Mooney