[openstack-dev] [Netstack] [Quantum] plugin -> backend
Bill Shetti
billshetti at gmail.com
Tue Aug 14 22:04:29 UTC 2012
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 <dan at nicira.com> wrote:
>
>
> On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti <billshetti at 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 <dan at nicira.com> wrote:
>>
>>>
>>>
>>> On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshetti at 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 <nachi at nttmcl.com> wrote:
>>>>
>>>>> 2012/8/2 Dan Wendlandt <dan at 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 <nachi at 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 <zhuadl at 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: zhuadl at 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 <dan at nicira.com>*
>>>>>>>>
>>>>>>>> 2012-07-31 14:45
>>>>>>>> Please respond to
>>>>>>>> OpenStack Development Mailing List <
>>>>>>>> openstack-dev at lists.openstack.org>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To
>>>>>>>>
>>>>>>>>
>>>>>>>> "Sumit Naiksatam (snaiksat)" <snaiksat at cisco.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> cc
>>>>>>>>
>>>>>>>>
>>>>>>>> OpenStack Development Mailing List <
>>>>>>>> openstack-dev at lists.openstack.org>, "
>>>>>>>> netstack at lists.launchpad.net" <netstack at lists.launchpad.net>,
>>>>>>>> Willian Molinari <willian.molinari at 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) <*
>>>>>>>> snaiksat at cisco.com* <snaiksat at 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.com at lists.launchpad.net
>>>>>>>> * <cisco.com at lists.launchpad.net> [mailto:*
>>>>>>>> netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
>>>>>>>> cisco.com at lists.launchpad.net* <cisco.com at 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 at lists.launchpad.net* <netstack at 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.com at lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net> wrote:
>>>>>>>> -----
>>>>>>>>
>>>>>>>> To: *"netstack at lists.launchpad.net"*<netstack at lists.launchpad.net>
>>>>>>>> *<netstack at lists.launchpad.net>* <netstack at lists.launchpad.net>
>>>>>>>> From: Willian Molinari
>>>>>>>> Sent by: *
>>>>>>>> netstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com at 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 at lists.launchpad.net*<netstack at 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 at lists.launchpad.net*<netstack at 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-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mailing list: https://launchpad.net/~netstack
>>>>>>>> Post to : netstack at lists.launchpad.net
>>>>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at 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-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~netstack
>>>>> Post to : netstack at lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~netstack
>>>> Post to : netstack at 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120814/e7119118/attachment-0001.html>
More information about the OpenStack-dev
mailing list