On 11.10.2013, at 22:58, "Rochelle.Grober"
<rochelle.gro...@huawei.com<mailto:rochelle.gro...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
