Open Stack

Starting from the existing code also makes migration for production environments currently using the code much easier.

Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure.

Tim

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: 22 November 2013 17:33
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> 
> On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote:
> > On 11/22/2013 11:17 AM, Jonathan Proulx wrote:
> > > To add to the screams of others removing features from nova-network
> > > to achieve parity with neutron is a non starter, and it rather
> > > scares me to hear it suggested.
> >
> > -1 from me too, so everyone can take a deep breath on this.  :-)
> >
> > > Providing feature parity and easy cut over *should have been*
> > > priority
> > > 1 when quantum split out of nova as it was for cinder (which was a
> > > delightful and completely unnoticable transition)
> >
> > +1
> >
> > I think the experience with Neutron provides us some very good insight
> > for future project splits/replacements.  We're working on establishing
> > more clear requirements for project incubation and graduation in the TC.
> >  One note I put down was that we should require that projects stay
> > completely focused on being able to deprecate their replacement before
> > adding *anything* else whenever possible.
> >
> > A good example is the current discussion around a new scheduling
> > service.  There have been lots of big ideas around this.  Robert
> > Collins just started a thread about a proposal to start this project
> > but with a very strict scope of being able to replace nova-scheduler,
> > and *nothing* more until that's completely done.  I like that approach quite a bit.
> 
> I'd suggest something even stronger. If we want to split out code into a new project, we should always follow the approach used for
> cinder.
> ie the existing fully functional code should be pulled out as is, and work then progress from there. That ensures we'd always have feature
> parity from the very start. Yes, you might have to then do a large amount of refactoring to get to where you want to be, but IMHO that's
> preferrable to starting something from scratch and forgetting to cover existing use cases.
> 
> 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 :|
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev