Le 05/09/2014 01:22, Michael Still a écrit :
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange <berra...@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

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.


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.


OpenStack-dev mailing list

Reply via email to