Open Stack

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

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

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

> Just my 2c.

Appreciated!!

> Thanks,
> 
> Steve
> 
> * https://blueprints.launchpad.net/neutron/+spec/quantum-multihost
>