Open Stack

On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
> On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
> > A handy example of this I can think of is the currently granted FFE for
> > serial consoles - consider how much of the code went into the common
> > part vs. the libvirt specific part, I would say the ratio is very close
> > to 1 if not even in favour of the common part (current 4 outstanding
> > patches are all for core, and out of the 5 merged - only one of them was
> > purely libvirt specific, assuming virt/ will live in nova-common).
> > 
> > Joe asked a similar question elsewhere on the thread.
> > 
> > Once again - I am not against doing it - what I am saying is that we
> > need to look into this closer as it may not be as big of a win from the
> > number of changes needed per feature as we may think.
> > 
> > Just some things to think about with regards to the whole idea, by no
> > means exhaustive.
> 
> So maybe the better question is: what are the top sources of technical
> debt in Nova that we need to address? And if we did, everyone would be
> more sane, and feel less burnt.
> 
> Maybe the drivers are the worst debt, and jettisoning them makes them
> someone else's problem, so that helps some. I'm not entirely convinced
> right now.
> 
> I think Cells represents a lot of debt right now. It doesn't fully work
> with the rest of Nova, and produces a ton of extra code paths special
> cased for the cells path.
> 
> The Scheduler has a ton of debt as has been pointed out by the efforts
> in and around Gannt. The focus has been on the split, but realistically
> I'm with Jay is that we should focus on the debt, and exposing a REST
> interface in Nova.
> 
> What about the Nova objects transition? That continues to be slow
> because it's basically Dan (with a few other helpers from time to time).
> Would it be helpful if we did an all hands on deck transition of the
> rest of Nova for K1 and just get it done? Would be nice to have the bulk
> of Nova core working on one thing like this and actually be in shared
> context with everyone else for a while.

I think the idea that we can tell everyone in Nova what they should
focus on for a cycle, or more generally, is doomed to failure. This
isn't a closed source company controlled project where you can dictate
what everyones priority must be. We must accept that rely on all our
contributors good will in voluntarily giving their time & resource to
the projct, to scratch whatever itch they have in the project. We have
to encourage them to want to work nova and demonstrate that we value
whatever form of contributor they choose to make. If we have technical
debt that we think is important to address we need to illustrate /
show people why they should care about helping. If they none the less
decide that work isn't for them, we can't just cast them aside and/or
ignore their contributions, while we get on with other things. This
is why I think it is important that we split up nova to allow each
are to self-organize around what they consider to be priorities in
their area of interest / motivation. Not enabling that is going to
to continue to kill our community

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