Ask Your Question
0

Why Linux bridge Quantum plugin ?

asked 2012-04-03 13:32:38 -0500

pns005 gravatar image

Hi Dan/Sumit/Salvatore and all,

Could you please share your thought on why a new cloud provider would choose to use Linux bridge Quantum plugin over say, OVS or Cisco plugin ?

Given the VLANs focus of this plugin, the 4k limitation is there - the very key issue that Quantum were to solve via appropriate plugin.

The one use case and the gateway setup description provided at http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin (http://wiki.openstack.org/Quantum-Lin...) appear to be very complicated to me. Mind you, I am far from being an expert in Cloud computing. But I do have plenty of experience in machine virtualization especially virtual switch and virtual network stack (L2).

The only benefit I could come up with is for those existing cloud providers who are not ready to move to a more virtualization focus software such as OVS and Cisco plugins and who the VLAN 4k limit is irrelevant i.e. small cloud, have other way to solve 4K VLAN limit etc.

Any other benefits ? What am I missing ?

Piyanai

edit retag flag offensive close merge delete

6 answers

Sort by ยป oldest newest most voted
0

answered 2012-04-03 15:09:36 -0500

Hi Piyanai,

That's a good question. It was done for at least a couple of reasons -

  • It was felt that a basic plugin was required (built on the lowest common denominator technology). It's good to have the option for basic setups and testing.

  • Since nova networking used a VLAN Manager based on a Linux Bridge, it was also felt that it would be good to have a corresponding implementation on the Quantum side (as we transitioned from a nova-network-based setup to Quantum and it's plugins).

However, I am not totally sure about your comment on the complicated setup part. By itself, it might appear to be complicated, but it's no more complicated than the setup for any other plugin. In fact, as I mentioned before, one of the reasons for doing this was to convey how a basic setup can be done. Note also that not all the steps shown in the diagram are steps required to be performed as a user (such as the gateway setup, those happen under the hood).

Thanks, ~Sumit.

-----Original Message----- From: bounces@canonical.com [mailto:bounces@canonical.com] On Behalf Of Piyanai Saowarattitada Sent: Tuesday, April 03, 2012 6:36 AM To: Sumit Naiksatam (snaiksat) Subject: [Question #192513]: Why Linux bridge Quantum plugin ?

New question #192513 on quantum: https://answers.launchpad.net/quantum/+question/192513 (https://answers.launchpad.net/quantum...)

Hi Dan/Sumit/Salvatore and all,

Could you please share your thought on why a new cloud provider would choose to use Linux bridge Quantum plugin over say, OVS or Cisco plugin ?

Given the VLANs focus of this plugin, the 4k limitation is there - the very key issue that Quantum were to solve via appropriate plugin.

The one use case and the gateway setup description provided at http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin (http://wiki.openstack.org/Quantum-Lin...) appear to be very complicated to me. Mind you, I am far from being an expert in Cloud computing. But I do have plenty of experience in machine virtualization especially virtual switch and virtual network stack (L2).

The only benefit I could come up with is for those existing cloud providers who are not ready to move to a more virtualization focus software such as OVS and Cisco plugins and who the VLAN 4k limit is irrelevant i.e. small cloud, have other way to solve 4K VLAN limit etc.

Any other benefits ? What am I missing ?

Piyanai


You received this question notification because you are a member of Netstack Core Developers, which is an answer contact for quantum.

edit flag offensive delete link more
0

answered 2012-04-03 16:48:04 -0500

pns005 gravatar image

Hi Sumit, thanks for the prompted response...

  • Since nova networking used a VLAN Manager based on a Linux Bridge, it was also felt that it would be good to have a corresponding implementation on the Quantum side (as we transitioned from a nova- network-based setup to Quantum and it's plugins).

So this plugin is mainly for Nova parity... Yep, had thought about this point also. But wonder if there is any other benefits.

ASSUMING (stressing a big assumption here) that Nova network continues to support VLAN Manager based on Linux Bridge for an unforeseeable future, what would be the incentive for new cloud provider to use Quantum Linux Bridge over VLAN Manager in NOVA ?

For Nova VLAN Manager/Linux Bridge, there is no additional service (Quantum) to have to set up let alone additional Quantum Linux Bridge plugin to install. Regardless of how simple Quantum and its plugins are to setup, these are still additional items to take care of. And don't forget that extra log files (quantum and may be its plugin) to monitor and analyze when things break.

However, I am not totally sure about your comment on the complicated setup part. By itself, it might appear to be complicated, but it's no more complicated than the setup for any other plugin.

Point taken. Let me clarify my statement... the complication part I referred to is specifically to the "Handling the Gateway Interface" paragraph on the wiki Snippet from the wiki: "There is a bit of complexity involved with creating and initializing the Gateway interface." Perhaps, the part that I had a hard time digesting is the separation of what I, as a user of this plugin, have to do to set the gateway interface up and what the plugin does behind the scene. My comment here is solely based on text in the plugin wiki alone. Have not explored the code base and/or any other documents (if any) for this plugin...

In a way, I am playing devil's advocate here... Personally, I think Quantum in general is the way to go for Cloud computing. It makes sense. It is providing a solid frame work for extending network side of instances (virtual world). Thus, I am not questioning why Linux Bridge plugin exists (Nova parity was the first thing came to mind) as much as I am interested in finding out additional benefits/incentives (if any) of picking this particular quantum plugin over other option, say existing Quantum plugins (to over come the VLAN 4k limit etc.) or even over the existing Nova VLAN Manager with Linux Bridge backing for that matter. For the latter, we assume that is a choice in the time frame I have.

Piyanai

edit flag offensive delete link more
0

answered 2012-04-03 17:03:25 -0500

danwent gravatar image

Hi Piyanai,

If you are using only the most basic features (L2 bridging + VLANs) the two plugins are probably rough similar both in terms of capabilities and difficulty of setup (the bridge plugin re-used a lot of the code from the open vswitch plugin).

The main reason to use the open vswitch plugin is if the cloud operator plans on using some of the capabilities that open vswitch has that are not supported on the linux bridge plugin. For example, the open vswitch plugin already supports an L2-in-L3 "overlay" tunneling mechanism to create private networks without VLANs in the physical infrastructure. There will be future work to expose additional advanced capabilities supported by OVS including QoS, packet filtering, monitoring, etc.

It should be pointed out that for Essex, Quantum is in incubation, meaning that may take special expertise to understand exactly what is or is not supported in a given deployment.

edit flag offensive delete link more
0

answered 2012-04-04 00:23:45 -0500

pns005 gravatar image

Thanks Dan!

I cannot agree more on your assessment especially the potential of important features provided by plugins such as OVS e.g. L2-in-L3 overlay etc.

It's partly the assessment along this line that triggered me to solicit input from the cloud experts out there about Linux Bridge plugin and its benefits. Looking down the road, depending on the business model, upgrading a cloud to acquire new feature is not an easy task especially from one plugin to another e.g. Linux Bridge to OVS perhaps... It could be very costly.

Note: Actually, this reminds me of something I have been thinking about for awhile now. What if Quantum has an ability to support multiple plugins simultaneously ? The key word here is "ability" (providing frame work in the API) rather than trying to make multiple plugins to work together harmoniously. Looking at your quantum-folsom etherpad, I can see at least one use case for this feature. Perhaps, a subject for another thread...

Back to the subject at hand, beside the Nova parity reasoning, I can't think of any other benefits using Linux Bridge plugin. Further, the simplicity reasoning (most Linux folks are already very familiar with the Linux Bridge plugin) is lessen when comparing usage of the plugin to the existing Nova VLAN Manager... not that it makes sense to compare as it's like comparing apples to oranges. Each network software set serves different goals in its own way - just right.

I would love to hear others' opinions on the subject. Thus, I will leave this thread opened for couple of days... If this mailing is not the place for this kind of discussion, please direct me to the right place.

Piyanai

edit flag offensive delete link more
0

answered 2012-04-08 21:23:27 -0500

danwent gravatar image

On Tue, Apr 3, 2012 at 5:25 PM, Piyanai Saowarattitada < question192513@answers.launchpad.net > wrote:

> >

Note: Actually, this reminds me of something I have been thinking about for awhile now. What if Quantum has an ability to support multiple plugins simultaneously ? The key word here is "ability" (providing frame work in the API) rather than trying to make multiple plugins to work together harmoniously. Looking at your quantum-folsom etherpad, I can see at least one use case for this feature. Perhaps, a subject for another thread...

From the FAQ on http://wiki.openstack.org/QuantumDevelopment (http://wiki.openstack.org/QuantumDeve...)

  • Q: Can I run multiple plugins at the same time?
  • A: No, only a single plugin can be run at a time. That said, this does not mean that you can only talk to one type of switch. One "plugin" can have multiple "drivers" that talk to different types of switches. For example, the Cisco plugin talks to multiple types of switches. There is no formal driver interface, but we encourage people to write the code that talks to a switch in a general way such that other plugins will be able to leverage it. A "driver" will usually be code that is able to talk to a particular switch model or family of switches. "drivers" usually will have methods for standard provisioning operations, like putting a port on a particular VLAN as the result of an attachment.

That said, when it comes to exposing new APIs, I expect that we will move in the direction of letting Quantum load multiple modules, each of which can expose different APIs.


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

edit flag offensive delete link more
0

answered 2012-04-14 14:09:28 -0500

pns005 gravatar image

Thanks Dan for the clarification especially around Quantum direction.

I think slide 37 of your http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 (http://www.slideshare.net/danwent/ope...) says it all.

That idea to support the "ability" to have multiple Quantum plugins came to mind when I was contemplating about all the new cool features - especially those beyond L2, - some of which are listed in the Folsom etherpad.

Looking forward to the discussions (remotely) next week at the summit - assuming the remote participation setup will be there...

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2012-04-03 13:32:38 -0500

Seen: 96 times

Last updated: Apr 14 '12