[openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers
Michael Still
mikal at stillhq.com
Thu Sep 4 23:22:18 UTC 2014
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
[Heavy snipping because of length]
> The radical (?) solution to the nova core team bottleneck is thus to
> follow this lead and split the nova virt drivers out into separate
> projects and delegate their maintainence to new dedicated teams.
>
> - Nova becomes the home for the public APIs, RPC system, database
> persistent and the glue that ties all this together with the
> virt driver API.
>
> - Each virt driver project gets its own core team and is responsible
> for dealing with review, merge & release of their codebase.
I think this is the crux of the matter. We're not doing a great job of
landing code at the moment, because we can't keep up with the review
workload.
So far we've had two proposals mooted:
- slots / runways, where we try to rate limit the number of things
we're trying to review at once to maintain focus
- splitting all the virt drivers out of the nova tree
Splitting the drivers out of the nova tree does come at a cost -- we'd
need to stabilise and probably version the hypervisor driver
interface, and that will encourage more "out of tree" drivers, which
are things we haven't historically wanted to do. If we did this split,
I think we need to acknowledge that we are changing policy there. It
also means that nova-core wouldn't be the ones holding the quality bar
for hypervisor drivers any more, I guess this would open the door for
drivers to more actively compete on the quality of their
implementations, which might be a good thing.
Both of these have interesting aspects, and I agree we need to do
_something_. I do wonder if there is a hybrid approach as well though.
For example, could we implement some sort of more formal lieutenant
system for drivers? We've talked about it in the past but never been
able to express how it would work in practise.
The last few days have been interesting as I watch FFEs come through.
People post explaining their feature, its importance, and the risk
associated with it. Three cores sign on for review. All of the ones
I've looked at have received active review since being posted. Would
it be bonkers to declare nova to be in "permanent feature freeze"? If
we could maintain the level of focus we see now, then we'd be getting
heaps more done that before.
These issues should very definitely be on the agenda for the design
summit, probably early in the week.
Michael
--
Rackspace Australia
More information about the OpenStack-dev
mailing list