Just a heads up. py36|7 jobs are stopped to run on tempest gate and the gate is unblocked, you can recheck your tempest patch. - https://review.opendev.org/c/openstack/tempest/+/842821 To drop py36|7 support in the tempest, we need to pin stable/ussuri with old tempest and work is in progress - https://review.opendev.org/q/topic:bug%252F1975036 - https://review.opendev.org/q/topic:ussuri-pin-tempest -gmann ---- On Wed, 25 May 2022 17:18:15 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
---- On Sat, 21 May 2022 11:23:10 -0500 Matthew Thode <mthode@mthode.org> wrote ----
On 22-05-20 20:13:52, Ghanshyam Mann wrote:
Hello Everyone,
As we know, in Zed cycle we have dropped the support of py3.6|7 from OpenStack which is why projects, lib like oslo started dropping it and made new releases. For example, oslo.log 5.0.0 does not support py3.6|7.
Tempest being branchless and still supporting stable/victoria onwards stable branches thought of keeping the py36|7 support. But with the oslo dropped py3.6|7 and upper constraint has been updated to the oslo lib latest version made Tempest unit py3.6|7 test jobs failed.
- https://bugs.launchpad.net/tempest/+bug/1975036
We have two options here:
1. requirements repo maintain different constraints for py3.6|7 and py3.8|9 which fix the Tempest py3.6| jobs and we can keep the python3.6|7 support in Tempest. Example: oslo.log which fixed the gate[1] but we might need to do the same for Tempest's other deps - https://review.opendev.org/c/openstack/requirements/+/842820
If we go this route, I think I'd like to have a separate file per python version. At that point 'unmaintained' versions of python/constraints could have their maintanece migrated to another team if needed. Also, the targets that are not for the current development cycle should have a comment stating such at the top of the file.
A problem with this is the sprawl of tests that could be needed.
2. Drop the support of py3.6|7 from Tempest If the requirement team is not ok with the above solution then we can think of dropping the py3.6|7 support from Tempest too. This will stop Tempest to run on py3.6|7 but it will not block Tempest to test the OpenStack running on py3.6|7 as that can be done by running the Tempest in virtual env.
One option is to generate th 36/37 constraints and putting the file in the tempest repo.
Yeah, even with this extra maintenance it will not be good as Tempest master supporting py36 will not be able to consume any of the new features from dependencies who already dropped py36.
We discussed it in QA meeting and agree to go with option 2 means dropping the py36|7 support in tempest too. I have started the work and most of the things are working.
- https://review.opendev.org/q/topic:bug%252F1975036
-gmann
Opinion?
NOTE: Until we figure this out, I have proposed to temporarily stop running py3.6|7 on tempest gate, (especially to get c9s volume detach failure fix to merged otherwise that will block other projects gate too)
- https://review.opendev.org/c/openstack/tempest/+/842821
[1] https://review.opendev.org/c/openstack/tempest/+/842819
-gmann
-- Matthew Thode