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