[openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Duncan Thomas duncan.thomas at gmail.com
Mon Aug 8 16:40:56 UTC 2016


On 8 August 2016 at 18:31, Matthew Treinish <mtreinish at kortar.org> wrote:

>
> 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.
>
>
Ok, to turn the question around, we (the cinder team) have recognised a
definite and strong need to have somewhere for vendors to share patches on
versions of Cinder older than the stable branch policy allows.

Given this need, what are our options?

1. We could do all this outside Openstack infrastructure. There are
significant downsides to doing so from organisational, maintenance, cost
etc points of view. Also means that the place vendors go for these patches
is not obvious, and the process for getting patches in is not standard.

2. We could have something not named 'stable' that has looser rules than
stable branches,, maybe just pep8 / unit / cinder in-tree tests. No
devstack.

3. We go with the Neutron model and take drivers out of tree. This is not
something the cinder core team are in favour of - we see significant value
in the code review that drivers currently get - the code quality
improvements between when a driver is submitted and when it is merged are
sometimes very significant. Also, taking the code out of tree makes it
difficult to get all the drivers checked out in one place to analyse e.g.
how a certain driver call is implemented across all the drivers, when
reasoning or making changes to core code.

Given we've identified a clear need, and have repeated rejected one
solution (take drivers out of tree - it has been discussed at every summit
and midcycle for 3+ cycles), what positive suggestions can people make?

-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160808/f8d3964f/attachment.html>


More information about the OpenStack-dev mailing list