python_requires >= 3.8 during Yoga

Sean Mooney smooney at
Wed Dec 1 17:05:34 UTC 2021

On Wed, 2021-12-01 at 09:13 -0700, Alex Schultz wrote:
> On Wed, Dec 1, 2021 at 9:04 AM Braden, Albert <abraden at> wrote:
> > 
> > It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving.
> > 
> I'm not certain why this is how it's being interpreted.  CentOS stream
> is perfectly viable but it is (as has always been) reliant on
> packaging.  I believe Cloud SIG will still exist and RDO will be
> publishing packages. In fact CentOS stream is generally better than
> the previous release cadence that caused all sort of issues when point
> releases dropped with breaking changes.  The difference in stream vs
> legacy method was the volume of changes over time.  Stream you get
> smaller changes sooner (along with fixes) where as the legacy method
> you'd only really get updates at point release time and it was always
> terrible troubleshooting these failures.   CentOS Stream 9 will have
> 3.9 as the default but we need to make sure that we can get it
> available to the various projects for testing.  Right now Puppet
> OpenStack primarily relies on CentOS for testing (because Ubuntu jobs
> have been broken for a few years now with no one jumping in to fix).
> So bumping the minimum version without having a way to deploy for us
> would directly impact this project.

at least internally earlier this year i reached out about rhel9/centos9 supprot 
specifcly related to py 3.9 support and eventlets.
my understandwing was there was already some basic rhel9/centos9 ci happening the puppet moduels
since eventlet supprot was tested using a puppet module job.

> IMHO the issue with this thread is timing on being able to bump a
> minimum python version requirement.  I personally wouldn't want to
> bump to something that excludes 3.6 at this time without a really good
> reason.

there is/was an expecation that rdo woudl backport support for cento 9 and py39 to stable wababy at
some point since our downstream osp 17 product will be based on rhel 9 on stable/walaby.

im not directly involved in that packaging effort but i had assumed perhaps incorreectly that redhat would
do that work upstream in rdo? is this not the case?

at least form a downstram perspective unless we cahnge direction and decided to build OSP 17 using ubi8 images
instead fo ubi9 we will need to do all this packaging work anyway so im surprised there is this much push back
to moving to centos 9 and py39.

>   Are there features we require that will suddenly make
> developer/operator lives easier (e.g. switching to asyncio or
> something)?
actuly they are a few nice libary enhanchments but that is not the main driving factor.

many do not want to support deploying the openstack project on python version we do not test.
so either we keep 3.6 support and test it in every porject or we drop it and test with 3.8 and 3.9.

>   If not, what is the driving factor?

i have been pushing for 3.9 testing to become required for all project because centos/rhel 9 will only ship 3.9+
and it will be what our downstream product will be based on and i belive 3.9 is already used on debian 11 and 3.10 i belive
is slated for ubuntu 22.04 which will be the next ubuntu lts and will supprot/ship openstack yoga.

so haveing at least 3.9  support in yoga will be imporatn for multiple distros and to help use test that i and proably others
suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9)

continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward
as it stops being shipped in distros and as it exits security support
the end of life for python 3.6 is planned for this month
speficically (23 Dec 2021) based on

i dont think we shoudl be releasing yoga on an end of life python version.
if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024
which is after the stabel branch will be retired.

not support python 3.9 and 3.10 for yoga will make packaging openstack very hard for many ditros but since we cant realticaly test 4 verions properly we
have to increase the minium verions at some point.
>   I think pushing it
> off to Z would be best to allow for the initial standup required to
> have *all* the projects able to support the switch.
all project where ment to start adding 3.9 support already it has been a non vovting test requiremtn for 2? cycles i belvie
since we knew it was gong to be used in debian 11 and centos 9 for well over a year.

i do agree that its unfortunet that centos 9 missed it release target and did not release before the start of the yoga cycle
but a better way to adress the upgrade issue i think woudl be to support xena/wallaby on centos 8 and 9 and make yoga 9 only.
if we need to supprot yoga on centos 8 because that is not possibel then we coudl keep 3.6 support for one addtional release i guss
but that wont be something that we just get for free and it will require use to reinstaet all 3.6 based ci and acnockolage that by the
time yoga is released 3.6 will be EOL.

> > Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning.
> > 
> > -----Original Message-----
> > From: Zane Bitter <zbitter at>
> > Sent: Wednesday, December 1, 2021 10:13 AM
> > To: openstack-discuss at
> > Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga
> > 
> > Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> > 
> > On 26/11/21 10:29, Ghanshyam Mann wrote:
> > >   ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur <dtantsur at> wrote ----
> > >   >
> > >   >
> > >   > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley <fungi at> wrote:
> > >   > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote:
> > >   > [...]
> > >   > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9.
> > >   > [...]
> > >   >
> > >   > Is this still true for CentOS Stream 9? The TC decision was to
> > >   > support that instead of CentOS Stream 8 in Yoga.
> > >   >
> > >   > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?).
> > > 
> > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is
> > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing
> > > 
> > > -
> > 
> > The guidelines the TC have set are not that something exists, but that
> > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide,
> > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable
> > LTS releases. It's not clear to me why CentOS Stream is the only distro
> > being treated differently.
> > 
> > The only difference is there is no plan for a CentOS-branded release to
> > define a point in time where Stream 9 becomes an LTS release. However,
> > other parties do have such plans, but pointedly have not done so: RHEL9
> > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to
> > release a version based on Stream 9.
> > 
> > Presumably RDO folks were consulted about this decision and were OK with
> > the time frame. However, there are other users out there, and from a
> > Metal³ perspective this is a giant PITA, requiring us to move from a LTS
> > distro to a beta one, that was dropped on us in the middle of a release
> > cycle in flagrant violation of the TC's own guidelines that the stable
> > distibutions must be chosen from among those available at the
> > *beginning* of the release cycle (which CentOS Stream 9 was not).
> > 
> > cheers,
> > Zane.
> > 
> > 

More information about the openstack-discuss mailing list