Open Stack

Like I mentioned before, I think the only way out of the Nova death
spiral is to split code and give control over it to smaller dedicated
review teams. This is one way to do it. Thanks Dan for pulling this
together :)

A couple comments inline:

Daniel P. Berrange wrote:
> [...]
> This is a crisis. A large crisis. In fact, if you got a moment, it's
> a twelve-storey crisis with a magnificent entrance hall, carpeting
> throughout, 24-hour portage, and an enormous sign on the roof,
> saying 'This Is a Large Crisis'. A large crisis requires a large
> plan.
> [...]

I totally agree. We need a plan now, because we can't go through another
cycle without a solution in sight.

> [...]
> This has quite a few implications for the way development would
> operate.
> 
>  - The Nova core team at least, would be voluntarily giving up a big
>    amount of responsibility over the evolution of virt drivers. Due
>    to human nature, people are not good at giving up power, so this
>    may be painful to swallow. Realistically current nova core are
>    not experts in most of the virt drivers to start with, and more
>    important we clearly do not have sufficient time to do a good job
>    of review with everything submitted. Much of the current need
>    for core review of virt drivers is to prevent the mis-use of a
>    poorly defined virt driver API...which can be mitigated - See
>    later point(s)
> 
>  - Nova core would/should not have automatic +2 over the virt driver
>    repositories since it is unreasonable to assume they have the
>    suitable domain knowledge for all virt drivers out there. People
>    would of course be able to be members of multiple core teams. For
>    example John G would naturally be nova-core and nova-xen-core. I
>    would aim for nova-core and nova-libvirt-core, and so on. I do not
>    want any +2 responsibility over VMWare/HyperV/Docker drivers since
>    they're not my area of expertize - I only look at them today because
>    they have no other nova-core representation.
> 
>  - Not sure if it implies the Nova PTL would be solely focused on
>    Nova common. eg would there continue to be one PTL over all virt
>    driver implementation projects, or would each project have its
>    own PTL. Maybe this is irrelevant if a Czars approach is chosen
>    by virt driver projects for their work. I'd be inclined to say
>    that a single PTL should stay as a figurehead to represent all
>    the virt driver projects, acting as a point of contact to ensure
>    we keep communication / co-operation between the drivers in sync.
> [...]

At this point it may look like our current structure (programs, one PTL,
single core teams...) prevents us from implementing that solution. I
just want to say that in OpenStack, organizational structure reflects
how we work, not the other way around. If we need to reorganize
"official" project structure to work in smarter and long-term healthy
ways, that's a really small price to pay.

-- 
Thierry Carrez (ttx)