Open Stack

On Wed, Sep 10, 2014 at 12:41:44PM -0700, Vishvananda Ishaya wrote:
> 
> On Sep 5, 2014, at 4:12 AM, Sean Dague <sean at dague.net> wrote:
> 
> > On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
> >> 
> >> 
> >> 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.
> 
> In my mind, spliting helps with all of these things. A lot of the cleanup
> related work is completely delayed because the review queue starts to seem
> like an insurmountable hurdle. There are various cleanups needed in the
> drivers as well but they are not progressing due to the glacier pace we
> are moving right now. Some examples: Vmware spawn refactor, Hyper-v bug
> fixes, Libvirt resize/migrate (this is still using ssh to copy data!)
> 
> People need smaller areas of work. And they need a sense of pride and
> ownership of the things that they work on. In my mind that is the best
> way to ensure success.

I do like to look at past experiance for guidance, and with Nova we have
had a history of splitting out pieces of code and I think it is fair to
say that all those splits have been very successful for both sides (the
new project and Nova). eg if we look at the size and scope of the cinder
project & team today, I don't think it could ever have grown to that
scale if it had remained part of Nova. Splitting it out unleashed its
latent potential for success.

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