Open Stack

Æ!!

> Suffice it to say we're not going to make any drastic changes with the time remaining on F-3, but I think we can talk about this at the Grizzly summit.

Yes. That was the main idea when I started the discussion. I know we can't start changing it for Folsom but it's a must have for Grizzly.  IHMO

--
Willian Molinari
(a.k.a PotHix)

________________________________
From: netstack-bounces+willian.molinari=locaweb.com.br at lists.launchpad.net [netstack-bounces+willian.molinari=locaweb.com.br at lists.launchpad.net] on behalf of Nachi Ueno [nachi at nttmcl.com]
Sent: Thursday, August 02, 2012 6:53 PM
To: OpenStack Development Mailing List
Cc: netstack at lists.launchpad.net
Subject: Re: [Netstack] [openstack-dev] [Quantum] plugin -> backend

2012/8/2 Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>>
Suffice it to say we're not going to make any drastic changes with the time remaining on F-3, but I think we can talk about this at the Grizzly summit.


I agree. This is reason why I implemented this function my plugin and extension.

We actually put a lot of thought into whether IPAM should have a separate plugin or not, and decided that the two where so tightly coupled that it didn't make sense.  We will be moving toward a model where higher level services (routers, loadbalancers, firewalls, etc.) can be implemented by plugins other than the core L2 + IPAM plugin.


I got use point ,but Coupling L2 + IPAM only makes sense when we use one L2 plugin.
It is normal large infrastructure uses multiple L2 technologies.

Nachi

Dan


On Thu, Aug 2, 2012 at 1:03 PM, Nachi Ueno <nachi at nttmcl.com<mailto:nachi at nttmcl.com>> wrote:
Hi Hua

I agree with you. Current plugin architecture is kind of silo.
My concern is about IPAM and L3.

-  IPAM
  IPAM plugin and L2 plugin can be different. However it is combined in current structure.

-  L3 function
 It needed to be connected each L2 plugin in L3.

They are a reason I'm proposing Metaplugin.
https://review.openstack.org/#/c/10181/ ( I'm very welcome your reviews!  :) )

By implementation of Metaplugin, I realized if each plugin will inherits QuantumDBPluginV2, and
 they do not use same table. We can use multiple plugin at once.
So at least IPAM will be solved.

Best
Nachi Ueno

2012/8/1 Hua ZZ Zhang <zhuadl at cn.ibm.com<mailto:zhuadl at cn.ibm.com>>

just add my cents here.

"Driver" concept make sense to my understaning. The current quantum underline plugins works and behaves more like network connectivity provider on top of specific type of device, from hardware and software, from vendors to open source. You can only enable ONE of it to provide virtual network service, but can't deploy without it.Just like database driver, it provide access of data backend and can't be absent. However plugin is not a essential part. Multiple plugins can be enabled at the same time in many software cases. They can work together with host to provide more functionalities.

Best Regards,


________________________________

Edward Zhang(张华)
Staff Software Engineer
Travel&Transportation Standards
Emerging Technology Institute(ETI)
IBM China Software Development Lab
e-mail: zhuadl at cn.ibm.com<mailto:zhuadl at cn.ibm.com>
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483


地址:北京市海淀区东北旺西路8号 中关村软件园28号楼 环宇大厦3层 邮编：100193
Address: 3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193


[X]




[Inactive hide details for Dan Wendlandt ---2012-07-31 14:50:45---Yes, we've had this discussion many times :) I agree that peop]Dan Wendlandt ---2012-07-31 14:50:45---Yes, we've had this discussion many times :) I agree that people find the term "plugin" confusing, but each time we've talked


Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>>

2012-07-31 14:45

Please respond to
OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>




To


"Sumit Naiksatam (snaiksat)" <snaiksat at cisco.com<mailto:snaiksat at cisco.com>>



cc


OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>" <netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>>, Willian Molinari <willian.molinari at locaweb.com.br<mailto:willian.molinari at locaweb.com.br>>



Subject


Re: [openstack-dev] [Netstack] [Quantum] plugin -> backend





Yes, we've had this discussion many times :)  I agree that people find the term "plugin" confusing, but each time we've talked about it, we've failed to find a single term that is substantially better to warrant the confusion likely to be caused by renaming.

In some cases I've started using the term "engine" when describing the plugin concept to people, since its really about a "pluggable backend" that powers the generic quantum API layer.  The name "driver" was very intentionally not chosen, as driver implies that it is specific to a particular type of back-end device, whereas a Quantum plugin is really more about an overall strategy of creating logical networks, etc.  For example, you could have a generic VLAN plugin that has drivers to talk to many different types of switches.

Dan

On Mon, Jul 30, 2012 at 7:55 PM, Sumit Naiksatam (snaiksat) <snaiksat at cisco.com<mailto:snaiksat at cisco.com>> wrote:

Hi,



I believe there are two topics of discussion here, one of which is the terminology. The way things are implemented today, I agree that the “plugin” terminology seems a bit confusing. However, probably the bigger topic of discussion is what kind of a design is preferable, “backend” versus “plugin”? As Yong points out, today’s Quantum service completely relies on the plugin for providing all functionality, including functionality that is probably common across plugins (like state management of logical resources, IPAM, etc.). Going forward, would it make sense to push some of the common functionality into the Quantum service, and have plugins which actually behave like the name suggests?



Thanks,

~Sumit.



From: netstack-bounces+snaiksat=cisco.com at lists.launchpad.net<mailto:cisco.com at lists.launchpad.net> [mailto:netstack-bounces+snaiksat<mailto:netstack-bounces%2Bsnaiksat>=cisco.com at lists.launchpad.net<mailto:cisco.com at lists.launchpad.net>] On Behalf Of Yong Sheng Gong
Sent: Monday, July 30, 2012 7:05 PM
To: Willian Molinari
Cc: OpenStack Development Mailing List; netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>
Subject: Re: [Netstack] [Quantum] plugin -> backend



Hi,
Add it into openstack-dev and [quantum] into the subject.

Yes, 'backend' seems better than 'plugin' for our case here.

Our plugin is a must for quantum server to work,  while 'plugin' tends to make us think it will provide more functionalities if we plug it in.
And I don't think our plugin is 'pluggable backend'.  I prefer to call it 'replaceable or configurable' 'backend' or 'dirver'.

Thanks
Yong Sheng Gong



-----netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net<mailto:-----netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net> wrote: -----

To: "netstack at lists.launchpad.net"<mailto:netstack at lists.launchpad.net> <netstack at lists.launchpad.net><mailto:netstack at lists.launchpad.net>
From: Willian Molinari
Sent by: netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net<mailto:netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net>
Date: 07/31/2012 07:26AM
Subject: [Netstack] plugin -> backend

Æ!!

Hi folks!

I was concerned to bring the "plugins" discussion because it looks like a bikeshedding
and it probably was discussed before, but I think it will be beneficial at all.

What motivated me to bring the discussion was the Metaplugin implementation
(https://review.openstack.org/#/c/10181/) that looks like a quantum backend implementing
support for plugins.

When we first looked into quantum we thought that quantum plugin was following the same
concept of all other plugins (ie we should install a lot of plugins to enhance the application)
 but we found that this is not the concept of quantum plugins, talking to Dan about this at
the openstack summit I found the real concept of quantum plugins and I heard some people
saying that plugins should be something like a "pluggable backend", so why not to call the
plugin just "backend"?

Looks natural to have just one backend at time and this backend should handle multiple
plugins if needed (the metaplugin case).

Sorry for bringing a non-technical discussion like this but every time someone asks me to
explain what quantum does I need to show plugins as "backends" to make sense.

I'm the only guy that think it's confusing? :P

Just want to hear your ideas about this topic.

--
Willian Molinari
(a.k.a PotHix)

--
Mailing list: https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack>
Post to     : netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack>
More help   : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to     : netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Mailing list: https://launchpad.net/~netstack
Post to     : netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/9d9bb10c/attachment-0001.html>