Open Stack

On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney <smooney at redhat.com> wrote:
>
> 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 verisign.com> 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?
>

It is, however, because it's not done it is not OK to just do the
switch. Really the issue is that you can't make a blanket switch until
much of the bootstrapping work has been completed which is why doing
the switch in Z makes more sense to allow for this.

> 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.
>

This is the same problem we had with the 7/8 switch where train was
ultimately the thing where we had to backport support for py2.7/py3
problems. I would have really preferred to not do this again with 8/9
but here we are.  IIRC, we managed to get Ussuri switched to centos8.
Due to the delay in 9 availability we weren't able to get it ready in
the Xena cycle. We do want to get it done in Yoga but because this
thread is about making mandatory, we need to wait until the switch has
been completed.

> >   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.
>

That's fine to push it as a goal, but I just think the goal needs to
be delayed until Z.  Is there anything that is broken in 3.9

> 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 https://www.python.org/dev/peps/pep-0494/#lifespan
> speficically (23 Dec 2021) based on https://endoflife.date/python
>
> 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.
>

So I guess the question is who do we use for language support EOLs?
My understanding is that Ubuntu 18.04's default was 3.6 which has
standard support until 2023[0] and CentOS Stream 8 will be supported
until 2024[1].  Both of which should exceed Yoga's support[2]?  With
all these arguments about LTS distros, it seems that we should be
using their support life cyles for the language versions and not
python's[3].

[0] https://wiki.ubuntu.com/Releases
[1] https://www.centos.org/cl-vs-cs/
[2] https://releases.openstack.org/
[3] https://devguide.python.org/#status-of-python-branches

> 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 redhat.com>
> > > Sent: Wednesday, December 1, 2021 10:13 AM
> > > To: openstack-discuss at lists.openstack.org
> > > 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 redhat.com> wrote ----
> > > >   >
> > > >   >
> > > >   > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley <fungi at yuggoth.org> 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
> > > >
> > > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst
> > >
> > > 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.
> > >
> > >
> >
> >
>