Open Stack

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: 11 October 2013 15:18
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Hyper-V] Havana status
> 
> > As a practical example for Nova: in our case that would simply include the
> following subtrees: "nova/virt/hyperv" and "nova/tests/virt/hyperv".
> 
> If maintainers of a particular driver would prefer this sort of
> autonomy, I'd rather look at creating new repositories.  I'm completely
> open to going that route on a per-driver basis.  Thoughts?

I think that all drivers that are officially supported must be treated in the same way.

If we are going to split out drivers into a separate but still official repository then we should do so for all drivers.  This would allow Nova core developers to focus on the architectural side rather than how each individual driver implements the API that is presented.

Of course, with the current system it is much easier for a Nova core to identify and request a refactor or generalisation of code written in one or multiple drivers so they work for all of the drivers - we've had a few of those with XenAPI where code we have written has been pushed up into Nova core rather than the XenAPI tree.

Perhaps one approach would be to re-use the incubation approach we have; if drivers want to have the fast-development cycles uncoupled from core reviewers then they can be moved into an incubation project.  When there is a suitable level of integration (and automated testing to maintain it of course) then they can graduate.  I imagine at that point there will be more development of new features which affect Nova in general (to expose each hypervisor's strengths), so there would be fewer cases of them being restricted just to the virt/* tree.

Bob