Open Stack

On Thu, Sep 04, 2014 at 03:54:28PM -0700, Stefano Maffulli wrote:
> Thanks Daniel for taking the time to write such deep message. Obviously
> you have thought about this issue for a long time and your opinion comes
> from deep personal understanding. I'm adding tags for neutron and
> cinder, as I know they're having similar conversations.
> 
> I don't have a strong opinion on the solution you and Kyle seem to be
> leaning toward, I just have a couple of comments/warnings below
> 
> On 09/04/2014 03:24 AM, Daniel P. Berrange wrote:
> > saying 'This Is a Large Crisis'. A large crisis requires a large
> > plan.
> 
> Not necessarily, quite the contrary indeed. To address and solve big
> problems, experience and management literature suggest it's a lot better
> to make *one* small change, measure its effect and make one more change,
> measure its effect, and on and on until perfection. The discussion
> triggered by TripleO about 'what to measure' goes in the right
> direction.[1]

FWIW, don't read too much into that particular paragraph/sentance -
it is a humourous joke/quote from a british TV comedy :-)

> Your proposal seem to require a long term investment before its effects
> can be visible, although some of the things necessary for the split will
> be needed anyway. Do you think there are small changes with high impact
> that we can refine in Paris and put in place for Juno?

If we wanted to do a short term improvement, we'd probably have to look
at relaxing the way we apply our current 2 x +2  == +A policy in some
way. eg we'd have to look at perhaps identifying core virt driver team
members, and then treating their +1s as equivalent to a +2 if given on
a virt-driver only change, and so setting +A after only getting one +2.

> The other comment I have is about the risks of splitting teams and
> create new ones whose only expertise is their company's domain. I'm
> concerned of the bad side effect of having teams in Nova Program with
> very limited or no incentive at all to participate in nova-common
> project since all they care about will be their little (proprietary)
> hypervisor or network driver. I fear we may end up with nova-common
> owned by a handful of people from a couple of companies, limping along,
> while nova-drivers devs throw stones or ignore.

> Maybe this worst case scenario of disenfranchised membership is not as
> bad as I think it would be, I'm voicing my concern also to gauge this
> risk better. What are your thoughts on this specific risk? How can we
> mitigate it?

One of the important things I think we need todo is firm up the nova
internal virt driver API to make it more well specified, as a way to
prevent some of the sloopy bad practice all the virt driers engage
in today. I still see a fairly reasonable number of feature requests
that will involve nova common code, so even with a virt driver split,
the virt driver teams are forced to engage with the nova common code
to get some non-trivial portion of their work done. So if virt driver
teams don't help out with nova common code work, they're going to find
life hard for themselves when they do have features that involve nova
common.

In many ways I think we are already suffering quite alot from the
problem you describe today in several ways. A large portion of the
people contributing to all the virt drivers only really focus their
attention on their own area of interest, ignoring nova common. I
cannot entirely blame them for that because learning more of nova
is a significant investment of effort. This is one of the reasons
we struggle to identify enough people with broad enough knowledge
to promote to nova core. I think I can also see parallels in the
relationship between the major projects (nova, neutron, cinder,
etc) and the olso project. It is hard go get the downsteam consumer
projects to take an active interest in work on oslo itself. This
was probably worse when oslo first started out, but it is now a
more established team.

I accept that splitting the drivers out from nova common will probably
re-inforce the separation of work to some degree. The biggest benefits
will come to the virt driver teams themselves by unblocking them from
all competing for the same finite core reviewer resource.  The remaining
nova core team will probably gain a little bit more time (perhaps 10-15%)
by not having to pay attention to the virt driver code changes directly
but overall it wouldn't be a drammatic improvement there. The overall
reduction in repo size might help new contributors get up the on-ramp
to being part of the team, since smaller codebases are easier to learn
in general.

Overall I don't have a knockout answer to your concern though, other
than to say we're already facing that problem to quite a large extent
and modularization as a general concept has proved quite successful
for the growth of openstack projects that have split out from nova
in the past.

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