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....@lists.launchpad.net wrote: -----
To: "netstack@lists.launchpad.net" <netstack@lists.launchpad.net>
From: Willian Molinari
Sent by: netstack-bounces+gongysh=cn.ibm....@lists.launchpad.net
Date: 07/31/2012 07:26AM
Subject: [Netstack] plugin -> backend
From: Willian Molinari
Sent by: netstack-bounces+gongysh=cn.ibm....@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.
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)
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
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
