Open Stack

Walter A. Boring IV <walter.boring at hpe.com> wrote:

>
>>> I think "currently active stable branches" is key there. These branches
>>> would no longer be "currently active". They would get an EOL tag when it
>>> reaches the end of the support phases. We just wouldn't delete the
>>> branch.
>> This argument comes up at least once a cycle and there is a reason we  
>> don't do
>> this. When we EOL a branch all of the infrastructure for running any ci  
>> against
>> it goes away. This means devstack support, job definitions, tempest skip  
>> checks,
>> etc. Leaving the branch around advertises that you can still submit  
>> patches to
>> it which you can't anymore. As a community we've very clearly said that  
>> we don't
>> land any code without ensuring it passes tests first, and we do not  
>> maintain any
>> of the infrastructure for doing that after an EOL.
>
> And it's this exact policy that has lead us to this mess we are in  
> today.   As a vendor that has customers that use OpenStack, we have to  
> support very old releases.  Customers in the wild do not like to upgrade  
> once they get OpenStack up and running because it's very difficult, time  
> consuming and dangerous to do.  We have customers still running Icehouse  
> and they will most likely won't upgrade any time soon.  Banks hate  
> upgrading software after they have customers running on it.   This is a  
> community wide problem that needs to be addressed.
>
> Because of this problem, (not being able to backport bug fixes in our  
> drivers), we have been left with forking Cinder on our own github to put  
> our driver fixes there.   This is a terrible practice for the OpenStack  
> community in general, and terrible for customers/users of OpenStack, as  
> we have N driver vendors that have N different mechanisms for getting bug  
> fixes to their customers.  I believe this is a major problem for users of  
> OpenStack and it needs to be addressed.

Right. And so the proper solution in line with OpenStack practices would be  
to allow vendors to own their plugins and maintain them, potentially for  
extensive time. The fact the Cinder team is unwilling [as it seems like  
from what I read in other replies to the thread] to provide that kind of  
extensibility to vendors is unfortunate. BTW do we have a write-up of  
reasons behind that?

> At the Cinder midcycle, we came up with a solution that would satisfy  
> Cinder customers, as Sean planned out.

All of them? I am not sure on that one. Some consumers may put some trust  
into stable branches, and may be surprised by patches landing there without  
upstream CI in place, undermining the promise the project made by adopting  
the stable:follows-policy tag.

> We acknowledge that it's a driver maintainer's responsibility to make  
> sure they test any changes that get into the stable branches, because  
> there is no infra support for running CI against the patches of old  
> stable branches. I think that risk is far better than the existing  
> reality of N cinder forks floating around github.   It's just no way to  
> ship software to actual customers.

If Cinder would give you a right hooking entry point for your plugin, you  
would not need to fork the whole thing just to extend your small isolated  
bit. You would live on upstream infrastructure while stable/* is alive,  
then move to your own git repo somewhere on the internet to provide more  
bug fixes [as some vendors do for neutron drivers].

Ihar