openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

Hi Syd,

On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan <slogan@xxxxxxxxxxxx> wrote:
> I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum?

Several Quantum plugins already have L3-over-L3 "overlay" tunneling
capability to provide private L2 tenant networks without VLANs.  These
plugins include the Open vSwitch plugin (completely free/open source)
and the Nicira NVP plugin (commercial).  I suspect others will add
this capability as well in the future, and in general its a great
example of the new network technologies that Quantum enables.

The blueprint above is actually complete and merged, but is actually
about letting tenants define "routers" that connect multiple L2
Quantum networks (e.g., to make multi-tier web applications).  These
routers can also provide access to external networks and implement
floating IPs.  We're still wrapping up the Folsom Quantum docs, but
hopefully this capability will be more clear soon.  Thanks,

Dan


>
> Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach?
>
> Thanks,
>
> syd
>
> -----Original Message-----
> From: openstack-bounces+slogan=broadcom.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+slogan=broadcom.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wendlandt
> Sent: Friday, September 07, 2012 9:57 AM
> 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 Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu <mathieu.rohon@xxxxxxxxx> wrote:
>> great work thanks;
>>
>> As you said the main missing feature of quantum is the multi-host L3-agent.
>> So I wonder if we can combine nova-network and quantum in a way that
>> nova-network is only used for L3 features?
>
> I agree that it would be great if there was a simple work around like
> that, but I think the core of the problem is the multi_host logic in
> nova-network is closely tied to the IP Address Management (IPAM) logic
> in nova.  Quantum has its own IPAM logic, as it supports more advanced
> scenarios like overlapping IP addresses on different networks.  As a
> result, I think trying to get the nova-network multi_host logic
> working with Quantum would be on the same order of difficultly has
> getting a multi_host equivalent working in Quantum.  I don't think its
> fundamentally hard, we just need to be spending our current Quantum
> cycles on testing, bug fixing, and documentation and so had to drop
> this feature for the Folsom release.
>
> Dan
>
>
>
>>
>>
>> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan@xxxxxxxxxx> wrote:
>>>
>>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon@xxxxxxxxx>
>>> wrote:
>>> > There is still the security filtering issue
>>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>>> > which prevent some cloud operator from using OVS.
>>> >
>>> > Do you have a workaround to use security group with OVS in folsom?
>>>
>>> Yes, it merged into Nova yesterday.
>>> https://bugs.launchpad.net/quantum/+bug/1039400
>>>
>>> We're still working on the new Quantum docs for Folsom, but if you're
>>> already familiar with using Quantum + Nova, the key difference is that
>>> you use should a libvirt vif-plugging config of
>>> LibvirtHybridOVSBridgeDriver, rather than just
>>> LibvirtOpenVswitchDriver .
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Sep 5, 2012 at 7:01 PM, 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.
>>> >>
>>> >> >
>>> >> > For the more adventurous, there could be any number of interesting
>>> >> > scenarios enabled by having access to ovs capabilities  (e.g.
>>> >> > tunneling)
>>> >>
>>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>>> >> someone to setup the tunnels and direct packets into them correctly.
>>> >> That's is exactly what the Quantum OVS plugin does and it is
>>> >> completely open source and freely available, so if people want to
>>> >> experiment with OVS tunneling, using Quantum would seem like the
>>> >> obvious way to do this.
>>> >>
>>> >> Dan
>>> >>
>>> >>
>>> >> --
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> Dan Wendlandt
>>> >> Nicira, Inc: www.nicira.com
>>> >> twitter: danwendlandt
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev@xxxxxxxxxxxxxxxxxxx
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~