Sorry - catching up. Makes sense.
So, then theoretically can one instantiate a call to quantum which can then intern enable a virtual network (for VXLAN) spanning OVS (Nicira's or the public version), and say a vendor specific one like Cisco N1k? On Mon, Aug 6, 2012 at 9:25 AM, Dan Wendlandt <d...@nicira.com> wrote: > > > On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshe...@gmail.com> wrote: > >> Hi, catching up, and sorry for the request for history... but here it is. > > > You can see a short explanation of this on the FAQ here: > http://wiki.openstack.org/QuantumDevelopment . Longer explanation below. > > > >> >> 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. >> > > This is the big misconception that I mentioned earlier in the thread. > There is nothing that limits a plugin to dealing with a single vendor > technology. A plugin defines a strategy for mapping from logical-layer > network resources (quantum networks, ports, etc.) to provider-layer network > constructs (e.g., VLANs, hypervisor NICs). For example, a simple plugin > might map each quantum network to a VLAN ID, which it assumes it trunked to > all switches. Even if these switches are from multiple vendors, a plugin > just needs a "driver" that allows it to configure VLANs on each type of > switch. Using multiple drivers at once is definitely possible in the > current model. > > Stepping back, a helpful way to think about a "plugin" is really "what > chunk of code do I invoke when API CRUD operations are performed for > networks, subnets, and ports"? Is it code that allocates a VLAN/tunnel-id > in a database and tries to communicate with switches? Is it code that just > proxies this call to an OpenFlow controller, which does the heavy lifting? > > > >> >> Ueno-san's metaplugin should basically - baseline in quantum. >> > > The ability to create "metaplugins" was actually part of the original > Quantum design... its just one more "strategy" for dispatching API calls. > The tricky part is that to date I've heard multiple different strategies > for how a metaplugin might decide which sub-plugin to dispatch to (Nachi's > is one reasonable approach), so hard-coding a particular meta-plugin > strategy seems unwise and unnecessary, given that a metaplugin works > perfectly fine already in the existing architecture. If at some point in > the future a particular approach becomes standard, then perhaps baking it > into the architecture would make sense. > > Dan > > > 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/%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> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> 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 >> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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
