Open Stack

Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the ability to provide Œcore review¹ status to people for reviewing
those parts of the code? We have enough talented people in OpenStack to be
able to write a driver above gerrit to enable that.
Fragmenting the project will be very unhealthy.
For what it is worth having a release date at the end of a vacation is
really bad. Look at the numbers:
http://stackalytics.com/report/contribution/nova-group/30
Thanks
Gary

On 9/4/14, 3:59 PM, "Thierry Carrez" <thierry at openstack.org> wrote:

>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)
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev