Open Stack

On 09/04/2014 07:22 PM, Michael Still wrote:
> 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.

Agreed. Honestly, this has been a really nice flow. I'd love to figure
out what part of this focus is capturable for normal cadence. This
realistically is what I was hoping slots would provide, because I feel
like we actually move really fast when we call out 5-10 things to go
look at this week.

	-Sean

-- 
Sean Dague
http://dague.net