[tc] dropping python 3.8 support for 2024.1

Dmitriy Rabotyagov noonedeadpunk at gmail.com
Wed Oct 11 20:41:26 UTC 2023


deprecateion are allowed in non slurps we just cant remove supprot for a
depreaction
that has not been release in slurp.


Yes, thanks for correcting me, that's eventually what I meant, though
picked misguiding words to the express that.


ingoring that for a moment the deprecation poilcy

only applies to aplciation feature we have never applied it to runtimes or
minium python
version.


I'm not sure it's specified in resolution? To be frank, dropping an
application feature is way less deal breaker then dropping python version,
imo. I would compare it more with bumping min libvirt version then (which
is not supported by some platform).

> Your upgrade path would be to first update your runtime on 2023.x from
python3.8 to 3.9/3.10 then upgrade to 2024.1.

Sorry, I can't agree here with you Clark. With that we can also drop
platforms as well and tell users to upgrade OS in between of SLURP releases.

I know I m a bit exaggerating here, but it's kinda close.

Simple example of operations life - we have to schedule all planned
maintenances in a 6month before doing them. And if our plan was, for
example, involving openstack upgrade to 2024.1, but then, from the blue
sky, despite decision that was just taken by TC, I see that I need to do
some OS upgrades before that, it would break plans quite dramatically. This
would put into position, that by the time of the next possible planned
maintenance OpenStack version I am using (and was supposed to be upgraded 6
month ago) is already unmaintained.

I am not saying that py3.8 drop is affecting us specifically in this way
(dropping a platform would though), but just giving a perspective that such
decisions might result in quite some overhead for end users, especially
when they in a way contradict with existing TC decisions. I'm not even
saying that such thing can easily deduct available time for upstream
contributions...

But also there should be a trust in TC decisions from end users, so that
they know these can't change overnight and can be relied on. As otherwise
it would be pretty much hard to convince enyone, that you can rely on
OpenStack as a project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20231011/12fd5b70/attachment.htm>


More information about the openstack-discuss mailing list