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.
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. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
