Mailing List Archive

Re: [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/"]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/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp
Re: [Quantum] plugin -> backend [ In reply to ]
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<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
Re: [Quantum] plugin -> backend [ In reply to ]
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>
> <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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [Quantum] plugin -> backend [ In reply to ]
Æ!!

@Sumit, I think we want to keep as it is because it makes sense for quantum to have one backend implementing the main APIs.

@Dan, "backend" solves the name confusion IMHO.

The name backend feels right to me because Quantum is not so useful without a backend, is just incomplete.
Quantum itself will be the front end for what should be done on the backend.

I just think we should move from the name "plugin" because it causes a lot of confusion for new contributors,
is difficult to understand its main idea. We felt this confusion when we started developing our plugin.

As Dan said, this is not the first time it was discussed, and I think some name changing would be beneficial.

--
Willian Molinari
(a.k.a PotHix)
________________________________
From: Dan Wendlandt [dan@nicira.com]
Sent: Tuesday, July 31, 2012 3:46 AM
To: Sumit Naiksatam (snaiksat)
Cc: Yong Sheng Gong; Willian Molinari; OpenStack Development Mailing List; netstack@lists.launchpad.net
Subject: Re: [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
~~~~~~~~~~~~~~~~~~~~~~~~~~~