[openstack-dev] [Netstack] [Quantum] plugin -> backend

Nachi Ueno nachi at nttmcl.com
Thu Aug 2 21:07:59 UTC 2012


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/709974a2/attachment-0001.html>


More information about the OpenStack-dev mailing list