Why Linux bridge Quantum plugin ?

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: <email address hidden> [mailto:<email address hidden>] 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
>
>
> 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 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.

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

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.

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

On Tue, Apr 3, 2012 at 5:25 PM, Piyanai Saowarattitada <
<email address hidden>> 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

   - 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: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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
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...