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

Ben Swartzlander ben at swartzlander.org
Mon Aug 8 18:08:25 UTC 2016


On 08/08/2016 12:40 PM, Duncan Thomas wrote:
> On 8 August 2016 at 18:31, Matthew Treinish <mtreinish at kortar.org
> <mailto: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.

This. (2) is what I thought we were proposing from the beginning. Add a 
requirement for 3rd party CI from the affected vendor to pass and I 
think it works and benefits everyone.

-Ben Swartzlander

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




More information about the OpenStack-dev mailing list