So when can one do this? Is there an architectural change in Quantum to keep track of resources also - effectively act like a controller?
Is there a blueprint on this? thanks BIll On Sun, Aug 12, 2012 at 3:33 PM, Dan Wendlandt <d...@nicira.com> wrote: > > > On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti <billshe...@gmail.com> wrote: > >> 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? > > > Yes, definitely. If its an all VXLAN setup, I would imagine a single > plugin making decisions that span the entire network (e.g., this quantum > network maps to this VXLAN ID) and then communicating that decision via > different drivers to switches from different vendors/open-source projects. > > Dan > > >> >> >> >> >> 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 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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
