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?
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
__________________________________________________________________________
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
