Open Stack

>
> we drop supprot for py38 and hten re-added it because some project were not
> ready to drop it. i stongly belive that was a mistake.
>

Well, I'm not ready to judge if it was a mistake or not - there were
good arguments from both sides. But from projects perspective (not
libraries) it was pretty much in line to stop supporting it for
2023.2, yes.


> if we dont drop supprot in 2024.1 then i think we must drop it in 2024.2
> i dont think it would be reasonable to ask porject to continue to supprot it and i honestly dont think it
> is a reasonbale ask for 2024.1 or 2023.2 i was very unhappy with teh late readdtion of it in may after it was
> finally removed.

Yes, absolutely, it must go away in 2024.2 for sure.

> > 1. Py3.8. is going to be supported by Ubuntu 20.04 until April 2025 at
> > worst, and then there's also ESM till 2030. I bet RHEL has smth like
> > that as well. So security backports for python packages and python
> > itself is not really our pain.
> we do not use packages form the disto in our testing outside the standar libary
> and intepreter so it is a problem for the libs we use from pypi

But how much is the security of packages a concern inside a
containerized CI, when we're talking about running unit testing only
(and not dropping it from setup.cfg)?

> > 2. We still can test things quite consistently, since we have all our
> > dependencies maintained in upper-constraints.. Basically due to U-C I
> > can build and install Ocata as of today with Py2.7 (I'm not saying
> > it's good or bad, just stating the fact)
> not entirly. in ci or a contienr yes but some of our deps will not compile
> on newer operating systems. i.e. to run nova's pep8 tox env on wallaby i need
> to create an vm/container to do that because it wont actully work on a modern
> operating system. the system packages that we leverage are too new and cause issues.

We still have Ubuntu 20.04 among nodepool images for older releases,
which can handle py3.8 nicely. So technically - there should be no
issues in getting dependencies. And even if external dependencies will
start dropping support - we have u-c specifically for this reason.


> you have already been given that notice as we notified everyone that ubuntu 20.04
> was last supported in 2023.1 an all othe supported distos in that release ship python 3.9+
> debian 11 and centos 9 stream both already use python 3.9, ubuntu 22.04 ships 3.10

Was you? As I can technically run python 3.8 pretty much easily on one
of the supported platforms. If I am opening PTI for 2023.2
(https://governance.openstack.org/tc/reference/runtimes/2023.2.html),
what I'm told is:
* I need to have ubuntu 22.04/Debian 11
* I need to have Python 3.10 or 3.9, but 3.8 is also a thing.

It's not said anywhere that I can't do py3.8 for $reasons on Ubuntu 22.04, am I?

> so this is not a issue for the removal of python 3.8
> i dont know of any suppproted distribution where openstack 2023.2+ was shiped on py38
> so keeping supprot in 2023.2 or 2024.1 seam academic to me. do we know of any operator
> or deployment that would actully deploy this way?
>

Have we _anywhere_ in our guidelines connected Python versions to
distros? On the contrary, in "Extending support and testing for
release with the newer disto version" I see:
"When any release bumps the minimum supported distro platform OR
python version", meaning these are 2 distinct things that are handled
separately?



> i think retoactivly adding platform and python version that were previously
> agreed to be drop undermines that platfrom and our ablity to maintain it.
> to be clear as a contibutoer and core review i felt underminded by the tc
> when python 3.8 was readded in may. and i felt like we sent the wrong message
> to operators because we said somethign was supproted when none of the testing runtim
> operationg systems supproted a unifed deployment of openstack on that versoin of python.

No, I don't think we were adding a platform retroactively? As of
today, what I see and read makes me think that platform and python
version are 2 distinct things.
Despite that I know, that intention was slightly different, but that
is what we need to deal with as of today. And I don't know how a
regular operator should guess that we inside the community perceive
this information differently.

However, I fully understand your frustration that support was
re-added. And I also agree that it was my fault as well to fail to see
the absence of a process for removing older python versions when we
were agreeing to remove it, which resulted in pretty much chaos once
this became happening, as there was not any alignment on how to
proceed.

And I totally agree that the message sent was wrong. But it was
already sent and I'm not sure it can be revoked as of today. So the
best we can do now, IMO, is to focus on making up a clean and
organized process for Python deprecation in 2024.2.