On Wed, Oct 11, 2023, at 1:41 PM, Dmitriy Rabotyagov wrote:
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.
I think users needing to catch up on external dependencies at the boundaries between slurp upgrades is the expectation, and what I described takes that into account. Basically for a release X consider any releases A, B, C that a user might be able to directly upgrade to X from. Make that possible. In this case we have through overlapping python versions on A and B between old and new allowing you to get to new on X. 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.
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.
We are one week post 2023.2 release. I think now is exactly the time to figure this stuff out for 2024.1. Yes, it could be done earlier, but I don't think it is too late to make decisions that allow the software to be sustainable into the future.