On Fri, Oct 13, 2023, at 10:57 AM, Ghanshyam Mann wrote:
---- On Fri, 13 Oct 2023 05:42:48 -0700 Brian Rosmaita wrote ---
On 10/11/23 2:30 PM, Ghanshyam Mann wrote: [snip]
But this is what we agreed in the below change in policy to keep python min version as much as we can. - https://review.opendev.org/c/openstack/governance/+/882154
I don't think dropping python 3.8 support for 2024.1 violates that agreement. Lines 35-38:
Projects should avoid removing Python versions that have not reached `End Of Life https://devguide.python.org/versions/>`_ without a solid reason. It is recommended to keep compatability with older Python versions as long as possible.
What we're disagreeing about is what counts as "a solid reason". The only distro mentioned anywhere in the "Tested Runtimes for 2024.1" document [0] that has python 3.8 as the default is Ubuntu 20.04, and we can't run master (2024.1 development) devstack on it. That strikes me as "a solid reason" not to support python 3.8 in 2024.1. Adding the fact that python 3.8 will stop receiving security fixes within 6 months of the 2024.1 release makes this reason even more solid.
I do not think so because previous to this project-team-guide change[1] we used to follow the policy what you described that "keep bumping the python min version which is available default on the supported distro LTS version" and we kept bumping python min version without any solid reason other than just because it is not available as default in any of the supported distro. Which end up as issue in last cycle and we changed our policy and updated the documentation of python PTI also.
There are two different but related issues here. First is having overlap with python versions across releases. I think it was TripleO that ran into trouble with a lack of overlap. We have this. python3.8 has been supported for years so users have many versions on which they can convert with overlap. This is something we should keep in mind for future versions though. The second is the one that you are referring to here and the underlying issue was out of order operations in removing support. Support was removed from libraries first. Libraries need to remove support last. Doing it out of order broke downstream consumers of the libraries. In both situations I'm sure we can coordinate and plan ahead better. I wouldn't characterize these as upgrades simply because no current LTS supports them. As I wrote in a previous email python3.8 will be EOL early in the lifetime of 2024.1. Historically we've seen this lead to problems. I think it is better for users to get a clear signal from us that we would prefer to avoid those issues entirely and have them update sooner. This is a solid reason in my opinion. If we need additional reasons Python 3.10 and 3.11 have improved performance. In theory, the sooner we drop older slower pythons the sooner we get faster gate round trips, more performant API servers, and so on. I have no profiled any of the OpenStack services to say what the improvement will be (if any), but we have seen significant improvements in Zuul.
I am not sure if we keep referring the old resolution 2018 you mentioned or the updated PTI documentation. If you feel it has to be updated through the resolution then I am ok to propose change[1] (but this change was accepted by ~7-8 TC members which seems same as pass it as resolution) to resolution but honestly saying we do not need everything in resolution and policy documentation should be something we can refer.
[1] https://review.opendev.org/c/openstack/governance/+/882154
-gmann