Open Stack

----- Original Message -----
> From: "Tom Fifield" <tom at openstack.org>
> To: "Steve Gordon" <sgordon at redhat.com>
> Cc: openstack-docs at lists.openstack.org
> Sent: Friday, July 26, 2013 8:20:49 PM
> Subject: Re: [Openstack-docs] Intro and example installations
> 
> On 26/07/13 11:36, Steve Gordon wrote:
> > ----- Original Message -----
> >> From: "Tom Fifield" <tom at openstack.org>
> >> To: openstack-docs at lists.openstack.org
> >> Sent: Friday, July 26, 2013 1:26:01 PM
> >> Subject: Re: [Openstack-docs] Intro and example installations
> >>
> >> On 19/07/13 13:22, Anne Gentle wrote:
> >>>     2) Isn't nova-network slated to be deprecated in Havana (
> >>>     https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network )?
> >>>
> >>>
> >>> Yes but neutron is not yet an acceptable replacement, nor do we know if
> >>> it will be in Havana. So my guess is that the work to deprecate
> >>> nova-network will be delayed again. I don't know this for certain,
> >>> though, so the safest thing for docs to do is to have the
> >>> easiest/simplest still use nova-networks. Happy to
> >>> hear dissension around this point but with lack of HA in L3 plus major
> >>> complexity of SDN I just don't think it's right to use neutron for the
> >>> simplest install.
> >>
> >> Nova-network was slated to be deprecated in Havana, but this has change
> >> and will now happen in Ice House, with potential removal in J release.
> >> Therefore, I personally still consider it a very valid option for an
> >> architecture :)
> > 
> > My suggestion is not that nova-network isn't a valid option but my main
> > concerns/feelings are that:
> 
> Cheers for the responses - all very well reasoned :) Some quick other
> considerations in-line for your thoughts!
> 
> > 1) We have the opportunity here to steer new deployers past what is still
> > looking like a fairly involved migration path when nova-network actually
> > is removed (regardless of timing).
> 
> Just for reference, this is one of the reasons for the delay of
> nova-network removal - the lack of progress on the migration path.
> Essentially, it won't be removed until there is an appropriate migration
> path. Liking the thinking, but will believe it when I see it :)

Right, what I think will be interesting here is what "appropriate" ends up being. With my "relative newbie" hat on I think some of the migrations even for different versions of the same project within OpenStack have left a bit to be desired up to this point.

> > 2) Software Defined Networking is by its nature a conceptually different
> > way of thinking about networking in the data center. As such while the
> > implementation of it in OpenStack (neutron) will likely get somewhat
> > friendlier (and various issues like HA of the L3 agent will be addressed*)
> > as it is bedded down I don't think that central element of conceptual
> > complexity that will eventually need to explained is necessarily going
> > away.
> 
> Absolutely. We should be doing a good job to explain the SDN future :)
> It's just about balance ... right now there are many people coming to
> learn OpenStack, and they want it 'easy'. SDN introduces new
> technologies and concepts above the level many people are comfortable
> with. Software packages that control the network, or storage resources
> are not new. However, doing so using methods other than iptables, and
> the linux bridging stack are really freaking people out, from what I've
> seen.

I was thinking about this over the weekend and wondering whether the appropriate approach to that would be to use Neutron with the LinuxBridge plug-in as the on-ramp which keeps the user in (slightly) more familiar territory. Currently the basic-install uses Neutron with the Open vSwitch plug-in. The bigger question around this kind of decision though (and nova-network V neutron for that matter) that I was talking to Anne about on Friday is nailing down exactly what networking use cases users have, which of them cover the biggest potential audience, and how they are best catered to.

> > 3) Somewhat related to (1) bolting neutron on as a choose your own
> > adventure component is possibly going to be more difficult than installing
> > it in the first place ;).
> 
> True. A potential related point is that there are many use cases which
> can only be satisfied well by neutron. Anything that has something to do
> with multiple datacentres, for example. So, looking at the migration
> paths - what do we have? Does someone set up a highly available (i.e. no
> downtime for network tech migration is acceptable) OpenStack without
> having a firm idea of whether they will move beyond one datacentre or
> not? If there is the slightest chance they will be needing the advanced
> features, starting with quantum is a good idea to avoid the hell. For
> others, nova-network and its eventual migration path will suit.

Exactly, that's the kind of question I think we need to find answers to in order to make the right decisions on this.

Thanks,

Steve