Open Stack

 ---- On Thu, 12 Oct 2023 05:02:11 -0700  Dmitriy Rabotyagov  wrote --- 
 > >
 > > 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?

Yes, also we need to keep in mind that testing runtime is minimum expectation of
supported/tested distro or python versions. We might not be able to support
more versions of distro but we can support/test more python versions which
can be done on distro old version images or install manually in new version images.

I also still feel dropping it in 2024.2 is better way where we give deprecation
in 2024.1 (SLURP) and so that any upgrade from 2024.1->2024.2 or 2025.1
will not be issue.

-gmann

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