Open Stack

On Wed, Oct 11, 2023, at 2:05 PM, Dmitriy Rabotyagov wrote:
>> 
>> 
>> It is more than an exaggeration: it just isn't realistic to support anything else in my opinion. You'll be stuck supporting ancient everything if you don't take a position like this.
>
> Then I'd say that SLURP approach should be cancelled as I'm not sure 
> any more what real-users situation it is solving then.
> And if 1 year is a too long period which makes everything "ancient".

It isn't one year. Python 3.8 has been out since October 2019, was part of the Ubuntu Focal release in April 2020, was first supported in OpenStack Victoria (October 2020), and if kept as part of the 2024.1 release would be kept alive in OpenStack until approximately October 2025.

Python 3.8 will be EOL'd by its maintainers in ~October 2024. We have seen that when python releases become EOL'd many libraries stop supporting that release. This potentially leads to gaps in security and general bugfixing. I think giving users a clear signal of when they should update runtimes before that runtime becomes problematic is a good thing.

>
> Because as I said, removal of py3.8 had been raised at beginning of 
> 2023.2 (and I bet everyone recall the mess we got into because of 
> that), when we _really_ could drop it, but just by handling that in a 
> better way. But now in non-SLURP I feel pretty much wrong in doing so.

This is the part I do not understand. What is the functional difference for operators going through an upgrade process if we drop it in the .1 release vs the .2 release? Let's draw up the resulting upgrade paths.

If 2023.2 had dropped python3.8:

  * Run 2023.1 on python3.8
  * Convert 2023.1 deployment to python3.10
  * Upgrade 2023.1 to 2023.2 or 2024.1

If 2024.1 drops python3.8 support:

  * Run 2023.1 on python3.8
  * Optionally upgrade deployment to 2023.2
  * Convert 2023.x to python3.10
  * Upgrade to 2024.1

There isn't a huge difference here. And in both cases users can still skip an OpenStack version in the upgrade process if they choose to do so. The only real difference is if we want people to continue running 2024.1 on python3.8 before converting to probably python3.11 or python3.12 at that point. I don't think that is the sort of signal we want to give because deployments in that situation are very likely to run into struggles with library updates.

>
> And again, I am not protecting py3.8 specifically, but I am standing 
> for expectations that we set by introducing SLURPs, which IMO was one 
> of the biggest deals for operators lately.