Open Stack

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.