Open Stack

On 08/09/2016 03:01 PM, Ihar Hrachyshka wrote:
> 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?

I'm not sure what OpenStack practices you're referring to. The only 
project I'm aware of which does out of tree drivers is Neutron, and 
Neutron is a very different kind of project architecture that's not very 
comparable to Cinder. Most projects keep their drivers in tree.

The best example of why this is good is Linux. If you tell the Linux 
people to take their drivers out of the tree I can guarantee you they'll 
laugh you out of the room. The reasons for their stance are many and I 
won't recount them here (unless you want me to).

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

The main customers for bugfixes are OpenStack distros (like RHOS).

Only a tiny minority of users deploy from upstream and those users tend 
to be sophisticated enough to do their own backports or to pull from 
vendor's forked repos anyways.

What we're trying to achieve is to make the lives of the distro 
maintainers easier by creating a clearing house for bugfix backports 
which is owned and operating by the upstream community.

Regarding the stable:follows-policy tag, I never proposed using the 
stable branches -- I proposed creating different branches specifically 
to avoid the surprise you're alluding to. The infra team suggested that 
maybe reusing the stable branches was a better option.

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

In theory you're right. We never touch stuff outside the drivers when we 
backport fixes. However, to maintain proper git histories and to be able 
to run the unit tests, etc, it's logistically simpler to fork the whole 
repo. It's trivially easy to verify that the all of the differences 
between a fork and its parent are limited to just the driver 
subdirectory, so in practice we do it this way. It makes cherry-picking 
into and out of these repos fairly painless.

-Ben Swartzlander

> Ihar
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev