openstack team mailing list archive

["Kyle Mestery (kmestery)" <kmestery@xxxxxxxxx>]

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