[openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Daniel P. Berrange berrange at redhat.com
Thu Sep 11 09:48:48 UTC 2014


On Thu, Sep 04, 2014 at 05:27:06PM +0000, Alessandro Pilotti wrote:
> This means that if we reach a point in which we agree to spin off the drivers in
> separate core projects, we need to consider how driver related CIs will be still
> included in the Nova review process, possibly with voting rights when the
> individual CI stability allows it. Having each third party CI to vote only on
> its spin-off driver project is not an option IMO, as it won’t catch regressions
> introduced in Nova that affect the drivers, including race conditions [5]

Yes, the 3rd party CI would still need to be run against the nova common
repos to ensure changes there don't cause regressions on the virt drivers
in question. I'd expect them to continue to be non-gating as they are today
though. THe 3rd party CI would only be gating on the virt driver repo.

> An interesting area of discussion is who is going to be part of the initial core
> teams for each new subproject. I truly appreciated the experience and help of
> the Nova core guys, so in order to allow a smoother transition I’d suggest to
> have for each new project (e.g. nova-compute-hyperv, nova-compute-vmware, etc)
> an initial core team consisting in one or two members of the current Nova
> sub-team and one Nova core, with ideally each patch reviewed by both the domain
> experts and the Nova core. The team could then go on its way by voting its own
> members as any other OpenStack project does.

The question of precisely who should be on the core team of each virt driver
will probably vary depending on the driver. In the Xen & libvirt cases, they
are already privileged to have several nova-core members who would naturally
also be core on the virt drivers. In the VMWare / HyperV cases, the idea
you mention of having a couple of existing nova cores (temporarily) join
their new teams would be a good way to bootstrap the new team.

Beyond those cores though, I think what I'd suggest is that we look at the
list of people who have contributed most code to each driver, and also the
people who have reviewed most code in each driver and finally people active
in the sub-team meetings. From those lists identify approx 5-10 top candidates
to form the nucleus of the new team. Once up & running for a few months they
can then look to promote any other candidates who show commitment to the
driver in question.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the OpenStack-dev mailing list