Mailing List Archive

Re: [openstack-dev] [Quantum] plugin -> backend
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@cn.ibm.com District, Beijing, P.R.C.100193
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483













Dan Wendlandt
<dan@nicira.com>
To
2012-07-31 14:45 "Sumit Naiksatam (snaiksat)"
<snaiksat@cisco.com>
cc
Please respond to OpenStack Development Mailing List
OpenStack <openstack-dev@lists.openstack.org>
Development , "netstack@lists.launchpad.net"
Mailing List <netstack@lists.launchpad.net>,
<openstack-dev@li Willian Molinari
sts.openstack.org <willian.molinari@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@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@lists.launchpad.net [mailto:
netstack-bounces+snaiksat=cisco.com@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@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@lists.launchpad.net wrote: -----


To: "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>
From: Willian Molinari
Sent by: netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to     : netstack@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
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@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@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@nicira.com>*
>
> 2012-07-31 14:45
> Please respond to
> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
>
>
>
> To
>
>
> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>
>
> cc
>
>
> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
> "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>, Willian
> Molinari <willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
> cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
> -----
>
> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net> *
> <netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
> From: Willian Molinari
> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
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@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@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@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@nicira.com>*
>>
>> 2012-07-31 14:45
>> Please respond to
>> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
>>
>>
>>
>> To
>>
>>
>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>
>>
>> cc
>>
>>
>> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
>> "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>,
>> Willian Molinari <willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
>> cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net
>> * <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>> -----
>>
>> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net> *
>> <netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>> From: Willian Molinari
>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>
>>> 2012-07-31 14:45
>>> Please respond to
>>> OpenStack Development Mailing List <openstack-dev@lists.openstack.org
>>> >
>>>
>>>
>>>
>>> To
>>>
>>>
>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>
>>>
>>> cc
>>>
>>>
>>> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
>>> "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>,
>>> Willian Molinari <willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
>>> cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>> -----
>>>
>>> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net> *
>>> <netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>> From: Willian Molinari
>>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~netstack
>>> Post to : netstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~netstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
Æ!!

> 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.

Yes. That was the main idea when I started the discussion. I know we can't start changing it for Folsom but it's a must have for Grizzly. IHMO

--
Willian Molinari
(a.k.a PotHix)

________________________________
From: netstack-bounces+willian.molinari=locaweb.com.br@lists.launchpad.net [netstack-bounces+willian.molinari=locaweb.com.br@lists.launchpad.net] on behalf of Nachi Ueno [nachi@nttmcl.com]
Sent: Thursday, August 02, 2012 6:53 PM
To: OpenStack Development Mailing List
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] [openstack-dev] [Quantum] plugin -> backend

2012/8/2 Dan Wendlandt <dan@nicira.com<mailto:dan@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@nttmcl.com<mailto:nachi@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@cn.ibm.com<mailto:zhuadl@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@cn.ibm.com<mailto:zhuadl@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


[X]




[.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@nicira.com<mailto:dan@nicira.com>>

2012-07-31 14:45

Please respond to
OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>




To


"Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com<mailto:snaiksat@cisco.com>>



cc


OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, "netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>" <netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>>, Willian Molinari <willian.molinari@locaweb.com.br<mailto:willian.molinari@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@cisco.com<mailto:snaiksat@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@lists.launchpad.net<mailto:cisco.com@lists.launchpad.net> [mailto:netstack-bounces+snaiksat<mailto:netstack-bounces%2Bsnaiksat>=cisco.com@lists.launchpad.net<mailto:cisco.com@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@lists.launchpad.net<mailto:netstack@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@lists.launchpad.net<mailto:-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote: -----

To: "netstack@lists.launchpad.net"<mailto:netstack@lists.launchpad.net> <netstack@lists.launchpad.net><mailto:netstack@lists.launchpad.net>
From: Willian Molinari
Sent by: netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net<mailto:netstack-bounces+gongysh=cn.ibm.com@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<https://launchpad.net/%7Enetstack>
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack>
More help : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
+1 on Pothix, I usually think that talk about rename is a bikeshedding attitude, but in this case it looks pretty important.

[]'s
Juliano Martinez


On Thursday, August 2, 2012 at 8:09 PM, Willian Molinari wrote:

> Æ!!
>
> > 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.
>
> Yes. That was the main idea when I started the discussion. I know we can't start changing it for Folsom but it's a must have for Grizzly. IHMO
>
> --
> Willian Molinari
> (a.k.a PotHix)
>
> From: netstack-bounces+willian.molinari=locaweb.com.br (http://web.com.br)@lists.launchpad.net [netstack-bounces+willian.molinari=locaweb.com.br (http://web.com.br)@lists.launchpad.net] on behalf of Nachi Ueno [nachi@nttmcl.com (mailto:nachi@nttmcl.com)]
> Sent: Thursday, August 02, 2012 6:53 PM
> To: OpenStack Development Mailing List
> Cc: netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> Subject: Re: [Netstack] [openstack-dev] [Quantum] plugin -> backend
>
> 2012/8/2 Dan Wendlandt <dan@nicira.com (mailto:dan@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@nttmcl.com (mailto:nachi@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@cn.ibm.com (mailto:zhuadl@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@cn.ibm.com (mailto:zhuadl@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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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@nicira.com (mailto:dan@nicira.com)>
> > > > 2012-07-31 14:45
> > > > Please respond to
> > > > OpenStack Development Mailing List <openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)>
> > > >
> > > >
> > > >
> > > >
> > > > To
> > > >
> > > > "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com (mailto:snaiksat@cisco.com)>
> > > >
> > > > cc
> > > >
> > > > OpenStack Development Mailing List <openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)>, "netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)" <netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)>, Willian Molinari <willian.molinari@locaweb.com.br (mailto:willian.molinari@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@cisco.com (mailto:snaiksat@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@lists.launchpad.net (mailto:cisco.com@lists.launchpad.net) [mailto:netstack-bounces+snaiksat (mailto:netstack-bounces%2Bsnaiksat)=cisco.com@lists.launchpad.net (mailto:cisco.com@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@lists.launchpad.net (mailto:netstack@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@lists.launchpad.net (mailto:-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net) wrote: -----
> > > > To: "netstack@lists.launchpad.net" (mailto:netstack@lists.launchpad.net) <netstack@lists.launchpad.net> (mailto:netstack@lists.launchpad.net)
> > > > From: Willian Molinari
> > > > Sent by: netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net (mailto:netstack-bounces+gongysh=cn.ibm.com@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 (https://launchpad.net/%7Enetstack)
> > > > Post to : netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> > > > Unsubscribe : https://launchpad.net/~netstack (https://launchpad.net/%7Enetstack)
> > > > More help : https://help.launchpad.net/ListHelp
> > > >
> > > > --
> > > > Mailing list: https://launchpad.net/~netstack
> > > > Post to : netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> > > > Unsubscribe : https://launchpad.net/~netstack
> > > > More help : https://help.launchpad.net/ListHelp
> > > >
> > > >
> > > >
> > > > --
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Dan Wendlandt
> > > > Nicira, Inc: www.nicira.com (http://www.nicira.com/)
> > > > twitter: danwendlandt
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > _______________________________________________
> > > > OpenStack-dev mailing list
> > > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >
> > > >
> > > > --
> > > > Mailing list: https://launchpad.net/~netstack
> > > > Post to : netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> > > > Unsubscribe : https://launchpad.net/~netstack
> > > > More help : https://help.launchpad.net/ListHelp
> > > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com (http://www.nicira.com)
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
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@nttmcl.com> wrote:

> 2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>>
>>>> 2012-07-31 14:45
>>>> Please respond to
>>>> OpenStack Development Mailing List <
>>>> openstack-dev@lists.openstack.org>
>>>>
>>>>
>>>>
>>>> To
>>>>
>>>>
>>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>>
>>>>
>>>> cc
>>>>
>>>>
>>>> OpenStack Development Mailing List <
>>>> openstack-dev@lists.openstack.org>, "netstack@lists.launchpad.net" <
>>>> netstack@lists.launchpad.net>, Willian Molinari <
>>>> willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>>>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
>>>> cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>>> -----
>>>>
>>>> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net>
>>>> *<netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>>> From: Willian Molinari
>>>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~netstack
>>>> Post to : netstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~netstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshetti@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@nttmcl.com> wrote:
>
>> 2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>>>
>>>>> 2012-07-31 14:45
>>>>> Please respond to
>>>>> OpenStack Development Mailing List <
>>>>> openstack-dev@lists.openstack.org>
>>>>>
>>>>>
>>>>>
>>>>> To
>>>>>
>>>>>
>>>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>>>
>>>>>
>>>>> cc
>>>>>
>>>>>
>>>>> OpenStack Development Mailing List <
>>>>> openstack-dev@lists.openstack.org>, "netstack@lists.launchpad.net"
>>>>> <netstack@lists.launchpad.net>, Willian Molinari <
>>>>> willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>>>>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=
>>>>> *cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>>>> -----
>>>>>
>>>>> To: *"netstack@lists.launchpad.net"* <netstack@lists.launchpad.net>
>>>>> *<netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>>>> From: Willian Molinari
>>>>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~netstack
>>>>> Post to : netstack@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
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@nicira.com> wrote:

>
>
> On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshetti@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@nttmcl.com> wrote:
>>
>>> 2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>>>>
>>>>>> 2012-07-31 14:45
>>>>>> Please respond to
>>>>>> OpenStack Development Mailing List <
>>>>>> openstack-dev@lists.openstack.org>
>>>>>>
>>>>>>
>>>>>>
>>>>>> To
>>>>>>
>>>>>>
>>>>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>>>>
>>>>>>
>>>>>> cc
>>>>>>
>>>>>>
>>>>>> OpenStack Development Mailing List <
>>>>>> openstack-dev@lists.openstack.org>, "netstack@lists.launchpad.net"
>>>>>> <netstack@lists.launchpad.net>, Willian Molinari <
>>>>>> willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>>>>>> [mailto:*netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>
>>>>>> =*cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>>>>> -----
>>>>>>
>>>>>> To: *"netstack@lists.launchpad.net"*<netstack@lists.launchpad.net>
>>>>>> *<netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>>>>> From: Willian Molinari
>>>>>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~netstack
>>>>>> Post to : netstack@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@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@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~netstack
>>> Post to : netstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~netstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti <billshetti@gmail.com> wrote:

> 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?


Yes, definitely. If its an all VXLAN setup, I would imagine a single
plugin making decisions that span the entire network (e.g., this quantum
network maps to this VXLAN ID) and then communicating that decision via
different drivers to switches from different vendors/open-source projects.

Dan


>
>
>
>
> On Mon, Aug 6, 2012 at 9:25 AM, Dan Wendlandt <dan@nicira.com> wrote:
>
>>
>>
>> On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshetti@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@nttmcl.com> wrote:
>>>
>>>> 2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>>>>>
>>>>>>> 2012-07-31 14:45
>>>>>>> Please respond to
>>>>>>> OpenStack Development Mailing List <
>>>>>>> openstack-dev@lists.openstack.org>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To
>>>>>>>
>>>>>>>
>>>>>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>>>>>
>>>>>>>
>>>>>>> cc
>>>>>>>
>>>>>>>
>>>>>>> OpenStack Development Mailing List <
>>>>>>> openstack-dev@lists.openstack.org>, "netstack@lists.launchpad.net"
>>>>>>> <netstack@lists.launchpad.net>, Willian Molinari <
>>>>>>> willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net*<cisco.com@lists.launchpad.net>
>>>>>>> [mailto:*netstack-bounces+snaiksat*<netstack-bounces%2Bsnaiksat>
>>>>>>> =*cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>>>>>> -----
>>>>>>>
>>>>>>> To: *"netstack@lists.launchpad.net"*<netstack@lists.launchpad.net>
>>>>>>> *<netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>>>>>> From: Willian Molinari
>>>>>>> Sent by: *netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net
>>>>>>> * <netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~netstack
>>>>>>> Post to : netstack@lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev@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@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~netstack
>>>> Post to : netstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~netstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~netstack
>>> Post to : netstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~netstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [openstack-dev] [Quantum] plugin -> backend [ In reply to ]
So when can one do this? Is there an architectural change in Quantum to
keep track of resources also - effectively act like a controller?

Is there a blueprint on this?

thanks
BIll


On Sun, Aug 12, 2012 at 3:33 PM, Dan Wendlandt <dan@nicira.com> wrote:

>
>
> On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti <billshetti@gmail.com> wrote:
>
>> 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?
>
>
> Yes, definitely. If its an all VXLAN setup, I would imagine a single
> plugin making decisions that span the entire network (e.g., this quantum
> network maps to this VXLAN ID) and then communicating that decision via
> different drivers to switches from different vendors/open-source projects.
>
> Dan
>
>
>>
>>
>>
>>
>> On Mon, Aug 6, 2012 at 9:25 AM, Dan Wendlandt <dan@nicira.com> wrote:
>>
>>>
>>>
>>> On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti <billshetti@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@nttmcl.com> wrote:
>>>>
>>>>> 2012/8/2 Dan Wendlandt <dan@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@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@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@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@nicira.com>*
>>>>>>>>
>>>>>>>> 2012-07-31 14:45
>>>>>>>> Please respond to
>>>>>>>> OpenStack Development Mailing List <
>>>>>>>> openstack-dev@lists.openstack.org>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To
>>>>>>>>
>>>>>>>>
>>>>>>>> "Sumit Naiksatam (snaiksat)" <snaiksat@cisco.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> cc
>>>>>>>>
>>>>>>>>
>>>>>>>> OpenStack Development Mailing List <
>>>>>>>> openstack-dev@lists.openstack.org>, "
>>>>>>>> netstack@lists.launchpad.net" <netstack@lists.launchpad.net>,
>>>>>>>> Willian Molinari <willian.molinari@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@cisco.com* <snaiksat@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@lists.launchpad.net
>>>>>>>> * <cisco.com@lists.launchpad.net> [mailto:*
>>>>>>>> netstack-bounces+snaiksat* <netstack-bounces%2Bsnaiksat>=*
>>>>>>>> cisco.com@lists.launchpad.net* <cisco.com@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@lists.launchpad.net* <netstack@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@lists.launchpad.net*<-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net> wrote:
>>>>>>>> -----
>>>>>>>>
>>>>>>>> To: *"netstack@lists.launchpad.net"*<netstack@lists.launchpad.net>
>>>>>>>> *<netstack@lists.launchpad.net>* <netstack@lists.launchpad.net>
>>>>>>>> From: Willian Molinari
>>>>>>>> Sent by: *
>>>>>>>> netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net*<netstack-bounces+gongysh=cn.ibm.com@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@lists.launchpad.net*<netstack@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@lists.launchpad.net*<netstack@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@lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mailing list: https://launchpad.net/~netstack
>>>>>>>> Post to : netstack@lists.launchpad.net
>>>>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev@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@lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~netstack
>>>>> Post to : netstack@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~netstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~netstack
>>>> Post to : netstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~netstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>