[openstack-dev] [Hyper-V] Havana status
Alessandro Pilotti
apilotti at cloudbasesolutions.com
Fri Oct 11 21:09:37 UTC 2013
On 11.10.2013, at 22:58, "Rochelle.Grober" <Rochelle.Grober at huawei.com<mailto:Rochelle.Grober at huawei.com>> wrote:
Pardon me for cutting out most of the discussion. I’d like to summarize a bit here and make a proposal.
Issues:
· Driver and Plugin writers for Nova (and other Core OpenStack projects) have a different development focus than core developers which can create both delays in getting submitted code reviewed and tensions between to two camps.
· It is in OpenStack’s best interests to have these driver/plugin writers participating in OpenStack development as their contributions help make OpenStack a more relevant and compelling set of products in the Cloud space
· Delays of reviews are painful to driver writers causing extra branching, lots of duplicated work, etc.
· Nova Core reviewers are overworked and are less versed on the driver/plugin code, architecture, issues which makes them a little averse to performing reviews on these patches
· [developers|reviewers] aren’t appreciated
· Tempers flair
Proposed solution:
There have been a couple of solutions proposed. I’m presenting a merged/hybrid solution that may work
· Create a new repository for the extra drivers:
o Keep kvm and Xenapi in the Nova project as “reference” drivers
o openstack/nova-extra-drivers (proposed by rbryant)
o Have all drivers other than reference drivers in the extra-drivers project until they meet the maturity of the ones in Nova
o The core reviewers for nova-extra-drivers will come from its developer pool. As Alessandro pointed out, all the driver developers have more in common with each other than core Nova, so they should be able to do a better job of reviewing these patches than Nova core. Plus, this might create some synergy between different drivers that will result in more commonalities across drivers and better stability. This also reduces the workloads on both Nova Core reviewers and the driver developers/core reviewers.
The Hyper-V driver is definitely stable, production grade and feature complete for our targets since Grizzly, the fact that we push a lot on the blueprints development side is simply because we see potential in new features.
So if a nova-extra-drivers projects means a ghetto for "B" class drivers, my answer is no way, unless they miss a CI gate starting from Icehouse. :-)
Getting back to the initial topic, we have only a small bunch of bug fixes that need to be merged for the features that got added in Havana, which are just staying in the review limbus and that originated all this discussion ("incidentally" all in Nova).
I still see our work completely independent from Nova, but getting along with the entire community has of course a value that goes beyond the merits of our driver or any other single aspect of OpenStack. My suggestion is to bring this discussion to HK, possibly with a few beers in front and sort it out :-)
o If you don’t feel comfortable with the last bullet, have Nova core reviewers do the final approval, but only for the obvious “does this code meet our standards?”
The proposed solution focuses the strengths of the different developers in their strong areas. Everyone will still have to stretch to do reviews and now there is a possibility that the developers that best understand the drivers might be able to advance the state of the drivers by sharing their expertise amongst each other.
The proposal also offloads some of the workload for Nova Core reviewers and places it where it is best handled.
And, no more sniping about participation. The driver developers will participate more because their vested interests are communal to the project they are now in. Maybe the integration of tests, etc will even happen faster and expand coverage faster.
And by the way, the statistics on participation are just that: statistics. If you look at rbryant’s numbers, they are different from Stackalytics which are different from Launchpad which are different from review.openstack.org<http://review.openstack.org>.
And as and fYI. Guess what? Anyone working on a branch, such as stable (which promotes the commercial viability of OpenStack) gets ignored for their contributions once the branch has happened. At least on Stackalytics. I don’t know about rbryant’s numbers.
--Rocky Grober
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131011/acf4c211/attachment.html>
More information about the OpenStack-dev
mailing list