Open Stack

On Thu, Sep 04, 2014 at 01:36:04PM +0000, Gary Kotton wrote:
> 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.

The consensus view at the summit was that, having tried & failed at getting
useful changes into gerrit, it is not a viable option unless we undertake a
permanent fork of the code base. There didn't seem to be any apetite for
maintaining & developing a large java app ourselves. So people we're looking
to start writing a replacement for gerrit from scratch (albeit reusing the
database schema).

Even if we did have such fine grained permissioning in gerrit or another
review tool, I'd still suggest a split because this is about more than just
the review team size. There are a number of other compelling benefits to
having fully separate drivers I've mentioned in the original thread & other
replies here.

> Fragmenting the project will be very unhealthy.

On the contrary, I think it will re-invigorate the project. The other
historical cases where open stack projects have split out code have
resulted in a pretty significant benefit for all involved. The testing
frameworks we have will help ensure that the virt drivers continue to
provide consistent semantics, just as they do today, and any eventual
openstack trademark certifications would re-inforce that. Improving
the specification of the virt driver interface by introducing more
objects and killing undocumented dict usage will also further help
in keeping virt drivers aligned.

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

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|