Open Stack

> It isn't one year.

We could drop things in April 2023 (for 2023.2, which we didn't do),
or we can drop them in April 2024 (for 2024.2), which is roughly 1
year? I think I was talking more about ability to strategically plan
such removal so that they were not matching non-SLURP releases.

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

Well, while I do agree with concerns here, I think it's missing some
important notes:
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.
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). Also the proposal is quite
clear to minimize testing to bare minimal, i.e. unit tests, so I don't
see how it's a deal breaker here. And it's in fact an operator's
responsibility to ensure their environments are secure enough.

> 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

Yes, that is right. Important thing here is that it would be expected.
Like I know in advance (with a year in my pocket), that in order to
upgrade to 2024.1 or to 2023.2 I need to upgrade python first, and
that is totally fine. So such thing can be planned, tested and
executed in 2 separate steps.

> 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

And here it's not precisely correct. As with that, upgrade to 2023.2
is not _really_ optional. And such upgrade (having temporary version
in between) from operational perspective is really a nightmare:
* Firstly it would take a 3x more time get the upgrade done (as you're
in fact doing 3 upgrades)
* Secondly you need to somehow explain the users that the API versions
(or microversions) you get in between is not smth you should get used
to, because it they will really soon
* Should you also upload new images for magnum/amphora/trove and
failover everything for this intermediate upgrade?
* Way more time you need to spend on testing such upgrade, as there's
another release now that needs to be handled.
* Last, but not least, each upgrade still brings some disturbance
(like restart of heat-engine might got stack borked), and now you need
to do that twice

So eventually, with all that, you come to the same flow as you
described if 2023.2 had dropped python3.8, meaning you should upgrade
your 2023.1 deployment to python3.10 and then proceed to 2024.1.
Except:
1. You relied on TC's decision that things will not be removed on
non-SLURP so invested your time into 2024.1 upgrade preparation(and
maybe development of features for 2024.1). Now you need to scrap all
your upgrade (or contribution) plans and plan python upgrade
internally instead, as this becomes basically a pre-requirement.
2. Python upgrade for operations is not only about OpenStack,
actually. As you also need to adopt your tooling, scripts and plenty
of stuff to work against the new Python version.
3. If you've already notified end-users to expect new features that
2024.1 will bring to them in 6 month - you have to disappoint them
now, since upgrades won't happen in that timeline, because you need to
deal with other things.


> I don't see a strong relationship with SLURP or non-SLURP

In the motivation part for SLURP there's that thing:
"Upgrades will be supported between “SLURP” releases, in addition to
between adjacent major releases (as they are today)."
IMO, with removing py38 now we're breaking that. If you're on 2023.1
and running py3.8 you can't just jump to 2024.1, which means that this
upgrade path is not _really_ supported. Or we really need to clarify
what we mean under "supported upgrades". I see how I can be wrong in
that assumption and that there're arguments against this vision. But I
assume this perspective has a right to exist as well.

Again. I really don't care about py3.8 as we are not running it since
upgrade to 2023.1 as switched to py3.10 right after it.
I'm more fighting for consistency between our decisions and actions
that we take afterwards, so that any openstack user or operator could
rely on decisions that were taken and promoted, so that OpenStack was
perceived as a solid platform.

чт, 12 окт. 2023 г. в 09:42, Sławek Kapłoński <skaplons at redhat.com>:
>
> Hi,
>
> Dnia czwartek, 12 października 2023 01:23:16 CEST Clark Boylan pisze:
> > 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.
>
> That's exactly my understanding. I don't see big difference there too.
>
> >
> > >
> > > 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.
> >
> >
>
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat