[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