Open Stack

Le 05/09/2014 01:22, Michael Still a écrit :
> 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

Ahem, IIRC, there is a third proposal for Kilo :
  - create subteam's half-cores responsible for reviewing patch's 
iterations and send to cores approvals requests once they consider the 
patch enough stable for it.

As I explained, it would allow to free up reviewing time for cores 
without loosing the control over what is being merged.

-Sylvain

> 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
>