Open Stack

 ---- On Sat, 21 May 2022 11:23:10 -0500 Matthew Thode <mthode at 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
 >