On 08/09/2016 03:01 PM, Ihar Hrachyshka wrote:
Walter A. Boring IV <walter.bor...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
