Open Stack

________________________________________
From: Alessandro Pilotti [apilotti at cloudbasesolutions.com]
Sent: 12 October 2013 20:21
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Hyper-V] Havana status

> 1) All the drivers will still be part of Nova.
> 
> 2) One official project (nova-drivers-incubator?) or more than one will be created for
> the purpose of supporting a leaner and faster development pace of the drivers.

I still think that all drivers should be treated equally; if we are to create a separate repository for drivers then I think we should officially split the driver repository out, including KVM and XenAPI drivers.  Certainly the XenAPI team have experienced a very similar issue with the time it takes to get reviews in - although I fully accept it may be to a lesser degree than Hyper-V.

> 3) Current driver sub-project teams will informally elect their maintainer(s) which will
> have +2a rights on the new project or specific subtrees.

The more I've thought about it the more I think we need common +2a's across all drivers to identify commonality before a one-big-drop and not per-driver +2a's.  Perhaps if there were dedicate "nova driver core" folk then the pace of driver development would be increased without sacrificing the good things we get by having people familiar with the expectations of the API, how other drivers implement things or identifying code that should not be written in drivers but moved to oslo or the main nova repository for the good of everyone rather than the specific driver.

> 4) Periodically, code from the new project(s) must be merged into Nova.
> Only Nova core reviewers will have obviously +2a rights here.
> I propose to do it on scheduled days before every milestone, differentiated per
> driver to distribute the review effort (what about also having Nova core reviewers
> assigned to each driver? Dan was suggesting something similar some time ago).

I don't think this is maintainable.  Assuming there is a high rate of change in the drivers, the number of changes that would likely need to be reviewed before each milestone could be huge and completely impossible to review - which could cause an even bigger issue.  I worry that if the Nova core reviewers aren't convinced by the code coming from this separate repository their choice would either be to reject the lot or just accept it without review.

> 5) All drivers will be treated equally and new features and bug fixes for master
> (except security ones) should land in the new project before moving to Nova.

Perhaps I don't understand this in relation to "nova-drivers-incubator" - but are you suggesting that new APIs are added to Nova, but their implementation is only added to nova-drivers-incubator until the scheduled day before the milestone, when the functionality can be moved into Nova?  If so I'm not sure of the benefit of having any drivers in Nova at all is, since the expectation would be you must always deploy the matching nova-drivers to get API compatibility.  Or are you suggesting that it is the developers choice about whether to push the new code to both repositories at the same time, or whether they want to wait for the big merge pre-milestone?

> 6) CI gates for all drivers, once available, will be added to the new project as
> well. Only drivers code with a CI gate will be merged in Nova (starting with the
> Icehouse release as we already discussed).

I think we can all agree on this one - although I thought the IceHouse expectation was not CI gate, but unit test gate and automated test (possibly through an external system) posting review comments.  Having said that, I would be very happy with enforcing CI gate for all drivers.

> 7) Active communication should be maintained between the Nova core team
> and the drivers maintainers. This means something more than: "I wrote it on the
> ML didn't you see it?" :-)

Definitely.  I'd suggest an IRC meeting - they are fun.

Bob