[openstack-dev] [Netstack] [Quantum] plugin -> backend
Bill Shetti
billshetti at gmail.com
Sat Aug 4 22:46:40 UTC 2012
Hi, catching up, and sorry for the request for history... but here it is...
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.
Ueno-san's metaplugin should basically - baseline in quantum.
Some education here would be helpful.
Unicast response is fine.
thanks
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/~netstack>
>>>> Post to : *netstack at lists.launchpad.net*<netstack at 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-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120804/cb32c8cd/attachment-0001.html>
More information about the OpenStack-dev
mailing list