[openstack-dev] [Netstack] [Quantum] plugin -> backend
Bill Shetti
billshetti at gmail.com
Fri Aug 10 01:47:27 UTC 2012
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 <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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120809/499870dd/attachment-0001.html>
More information about the OpenStack-dev
mailing list