Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom - rohon mathieu - net.launchpad.lists.openstack

22 messages in net.launchpad.lists.openstackRe: [Openstack] [openstack-dev] Quant...

From	Sent On	Attachments
Dan Wendlandt	Aug 24, 2012 3:38 pm
Rob_...@Dell.com	Aug 26, 2012 12:39 pm
Chris Wright	Aug 27, 2012 9:20 am
Dan Wendlandt	Aug 27, 2012 10:56 am
Rob_...@Dell.com	Sep 3, 2012 10:47 am
Gary Kotton	Sep 3, 2012 11:14 pm
Trey Morris	Sep 4, 2012 1:16 pm
andi abes	Sep 5, 2012 5:22 am
Salvatore Orlando	Sep 5, 2012 5:42 am
Dan Wendlandt	Sep 5, 2012 9:55 am
Dan Wendlandt	Sep 5, 2012 10:01 am
Chris Wright	Sep 5, 2012 12:24 pm
Kyle Mestery (kmestery)	Sep 5, 2012 1:14 pm
Syd (Sydney) Logan	Sep 5, 2012 1:59 pm
andi abes	Sep 5, 2012 2:49 pm
rohon mathieu	Sep 6, 2012 12:50 am
Dan Wendlandt	Sep 6, 2012 9:29 am
rohon mathieu	Sep 7, 2012 8:36 am
Dan Wendlandt	Sep 7, 2012 9:56 am
Syd (Sydney) Logan	Sep 7, 2012 10:34 am
Dan Wendlandt	Sep 7, 2012 11:11 am
Syd (Sydney) Logan	Sep 7, 2012 12:01 pm

Subject:	Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
From:	rohon mathieu (math...@gmail.com)
Date:	Sep 7, 2012 8:36:15 am
List:	net.launchpad.lists.openstack

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?

On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <da...@nicira.com> wrote:

On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <math...@gmail.com> 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 .

On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <da...@nicira.com> wrote:

On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi...@gmail.com> wrote:

late to the party... but I'll dabble.

On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chr...@sous-sol.org> wrote:

* Rob_...@Dell.com (Rob_...@Dell.com) 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.

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets