2012/8/2 Dan Wendlandt <d...@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 <na...@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 <zhu...@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: zhu...@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 >>> >>> >>> >>> >>> >>> >>> >>> [image: 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 <d...@nicira.com>* >>> >>> 2012-07-31 14:45 >>> Please respond to >>> OpenStack Development Mailing List <openstack-...@lists.openstack.org >>> > >>> >>> >>> >>> To >>> >>> >>> "Sumit Naiksatam (snaiksat)" <snaik...@cisco.com> >>> >>> >>> cc >>> >>> >>> OpenStack Development Mailing List <openstack-...@lists.openstack.org>, >>> "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>, >>> Willian Molinari <willian.molin...@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) <* >>> snaik...@cisco.com* <snaik...@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....@lists.launchpad.net*<cisco....@lists.launchpad.net> >>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=* >>> cisco....@lists.launchpad.net* <cisco....@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@lists.launchpad.net* <netstack@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....@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm....@lists.launchpad.net> >>> wrote: >>> ----- >>> >>> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net> * >>> <netstack@lists.launchpad.net>* <netstack@lists.launchpad.net> >>> From: Willian Molinari >>> Sent by: >>> *netstack-bounces+gongysh=cn.ibm....@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm....@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/*<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@lists.launchpad.net*<netstack@lists.launchpad.net> >>> Unsubscribe : >>> *https://launchpad.net/~netstack*<https://launchpad.net/%7Enetstack> >>> More help : >>> *https://help.launchpad.net/ListHelp*<https://help.launchpad.net/ListHelp> >>> >>> -- >>> Mailing list: >>> *https://launchpad.net/~netstack*<https://launchpad.net/~netstack> >>> Post to : >>> *netstack@lists.launchpad.net*<netstack@lists.launchpad.net> >>> Unsubscribe : >>> *https://launchpad.net/~netstack*<https://launchpad.net/~netstack> >>> More help : >>> *https://help.launchpad.net/ListHelp*<https://help.launchpad.net/ListHelp> >>> >>> >>> >>> >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Dan Wendlandt >>> Nicira, Inc: *www.nicira.com* <http://www.nicira.com/> >>> twitter: danwendlandt >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> _______________________________________________ >>> OpenStack-dev mailing list >>> openstack-...@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> -- >>> Mailing list: https://launchpad.net/~netstack >>> Post to : netstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~netstack >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> openstack-...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > _______________________________________________ > OpenStack-dev mailing list > openstack-...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
