Open Stack

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.


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.

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