openstack team mailing list archive

["Syd (Sydney) Logan" <slogan@xxxxxxxxxxxx>]

Backporting *would* duplicate work, by definition. 

This is nothing new in the industry, the need to innovate and move forward is always at odds with the need to support legacy deployments.

Seems to me quantum is a bit of an inflection point in the life of this rather young platform, and should be considered a forcing function for those who were earlier adopters to move forward.  Here's why:

One of the strongest points of quantum (in the scope of this discussion) is that it is a decoupling from nova, which should make issues like upgradability easier (assuming good API management) because it introduces an abstraction layer + implementation encapsulation. I would argue that while it might be painful to upgrade now, doing so just to get the encapsulation that quantum provides now is reason enough to want to push forward, especially since the gulf between the two will only widen going forward.

This topic of upgrading is an interesting one (perhaps one already discussed, I'm still a noob). Devstack, as useful as it is, hasn't reached its potential -- imagine it being shipped with a set of schemas (localrcs) for various deployments styles, e.g., multi-node vs single node, VXLAN vs NVGRE, X vs Y vs Z, or maybe providing a tool something like make menuconfig, or (eventually) the ability to "size up" a prior deployment and seamlessly upgrade it to a version with not much, if any, user interaction, as one might experience in the majority of cases when upgrading Ubuntu LTS releases.   Worlds like this are going to be more easily implemented on top of a platform that has good API management, modularity, and encapsulation of its core components, and standardizations for how the metadata of a deployment is specified and recorded (/etc/nova/nova.conf, etc. probably already fill that role). Quantum seems to me to be a necessary (IMHO) step in that direction.

Just my two cents.

syd

-----Original Message-----
From: openstack-bounces+slogan=broadcom.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+slogan=broadcom.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Kyle Mestery (kmestery)
Sent: Wednesday, September 05, 2012 1:15 PM
To: OpenStack Development Mailing List
Cc: <openstack-operators@xxxxxxxxxxxxxxxxxxx>; andi abes; <openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

On Sep 5, 2012, at 2:25 PM, Chris Wright wrote:
> * Dan Wendlandt (dan@xxxxxxxxxx) wrote:
>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes@xxxxxxxxx> wrote:
>>> late to the party... but I'll dabble.
>>> 
>>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw@xxxxxxxxxxxx> wrote:
>>>> * Rob_Hirschfeld@xxxxxxxx (Rob_Hirschfeld@xxxxxxxx) wrote:
>>>>> We've been discussing using Open vSwitch as the basis for non-Quantum Nova Networking deployments in Folsom.  While not Quantum, it feels like we're bringing Nova Networking a step closer to some of the core technologies that Quantum uses.
>>>> 
>>>> To what end?
>>> 
>>> OVS provides much more robust monitoring and operational facilities
>>> (e.g sFlow monitoring, better switch table visibility etc).
>> 
>> You won't find any disagreement from me about OVS having more advanced
>> capabilities :)
>> 
>>> It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> [1]), which should work out-of-box with the linux-bridge. As such,
>>> switching to using OVS rather than the linux bridge could be done
>>> without any code changes to nova, just deployment changes (e.g. ensure
>>> that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>> 
>> Using ovs-brcompatd would be possible, though some distros do not
>> package and run it by default and in general it is not the "preferred"
>> way to run things according to email on the OVS mailing list.
> 
> Indeed.  While it's doable, it's not something that will hit upstream
> Linux, and therefore will not be supported by some distros.
> 
> But, in general...while adding OVS support to nova networking (in the
> simplest layer 2 switch mode), may not be much work.  It's adding a (not
> particularly useful) feature to a code base that we hope to deprecate.
> And making it more useful (adding things like tunnelling) support are
> really the point of Quantum.
> 
I think that's what this really boils down to: The entire point of Quantum was to
add feature-rich networking as it's own service to OpenStack. Hedging by
adding piecemeal features to nova-net at this point may seem ok, but it's
a slippery slope, and may end up duplicating work which has already happened
in Quantum.

Thanks,
Kyle

> thanks,
> -chris
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp