Hi, catching up, and sorry for the request for history... but here it is...
What compelled the original decision to be made on enabling only ONE plugin/backend (whatever you want to call it)? Ideally you will want to instantiate multiple services from different vendors etc. Ueno-san's metaplugin should basically - baseline in quantum. Some education here would be helpful. Unicast response is fine. thanks Bill On Thu, Aug 2, 2012 at 2:07 PM, Nachi Ueno <na...@nttmcl.com> wrote: > 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 > >
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
