[openstack-dev] [Netstack] [Quantum] plugin -> backend
Hua ZZ Zhang
zhuadl at cn.ibm.com
Thu Aug 2 03:27:52 UTC 2012
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(张华) 地址:北京市海淀区东北旺西路8号 中关村
Staff Software Engineer 软件园28号楼 环宇大厦3层 邮编：100193
Travel&Transportation Standards Address: 3F Ring, Building 28
Emerging Technology Institute(ETI) Zhongguancun Software Park, 8
IBM China Software Development Lab Dongbeiwang West Road, Haidian
e-mail: zhuadl at cn.ibm.com District, Beijing, P.R.C.100193
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483
Dan Wendlandt
<dan at nicira.com>
To
2012-07-31 14:45 "Sumit Naiksatam (snaiksat)"
<snaiksat at cisco.com>
cc
Please respond to OpenStack Development Mailing List
OpenStack <openstack-dev at lists.openstack.org>
Development , "netstack at lists.launchpad.net"
Mailing List <netstack at lists.launchpad.net>,
<openstack-dev at li Willian Molinari
sts.openstack.org <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> 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 [mailto:
netstack-bounces+snaiksat=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
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 wrote: -----
To: "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
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/) 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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
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/582647d7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 33816049.gif
Type: image/gif
Size: 1279 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/582647d7/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/582647d7/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/582647d7/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic10457.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120802/582647d7/attachment-0007.gif>
More information about the OpenStack-dev
mailing list
