Open Stack

Hi Ying,

*1.  Extension standard.*

*One extension could be added is "attribute extension" to existing
resources. In our use case, we need to create Portprofile and later refer it
as a port's attribute. With current framework, we can create "Portprofile"
as a resource through "ResourceExtension". But how does the plug-in know
about this extension and refer the portprofile when the port is created?*

If by 'attribute extension' you mean something like adding the portprofile
info to the get response of the port resource, this can be handled through
the current RequestExtension. The RequestExtensionTest in test_extensions.py
should give you an example of this.
While creating either the RequestExtension or the ResourceExtension, you
would have added some sort of a handler for it. Now this handler should be
able to call the plugin code that adds/retrieves the port profile. All this
custom Extensions code would be sitting in a configurable folder within
quantum itself to make this possible. Jorge or the Titans could correct me
if im wrong on on any of this.

   *2. Relationship between extension and plug-in.*

Extensions is the middleware which can call plugin code. The plugin
code need not know about extensions at all.
A Plugin that has special features would need a specific extension that
would be able to expose resources or actions or attributes by calling the
plugin code.
If a single extension wants to cater to multiple plugins, that is also
possible if these plugins have a uniform interface that the extension can
understand.

When we consider extensions along with plugins we could have some new
scenarios to consider.
One of them is the ability to switch off extensions based on the plugin
loaded.
Right now all extensions are enabled by default, we dont have a way of
turning off extensions (i think). This could cause problems when plugins
have specific extensions. Since we load all extensions, extensions that dont
make sense to the currently loaded plugin will still be enabled. Loading all
extensions will also cause confusion to a client making the GET /extensions
call. This call would return extensions of all the plugins instead of
listing only those extensions that can work with the current plugin.
This could be fixed in a couple of ways that I can think of right now:
1) We could enhance the extension framework to load extensions from multiple
folders (Currently all extensions are expected to be in a single folder).
    Then we can keep plugin specific extensions in their own folders, and
change configuration to load only those folders that make sense for the
current plugin.
2) The Extension framework could ask each extension if it should load the
extension.
    Then, each plugin specific extension could check if its plugin is loaded
and decide whether it should also be loaded.

Thanks,
Rajaram


On Fri, Jun 10, 2011 at 2:49 AM, Troy Toman <troy.toman at rackspace.com>wrote:

>  Ying,
>
>  I can provide some insight since I am in the current timezone. Comments
> below. Perhaps Santhosh or are team can provide some additional thoughts
> later.
>
>  Troy
>
>  On Jun 9, 2011, at 4:10 PM, Ying Liu (yinliu2) wrote:
>
>   Hi all,
>
>  Thanks Santhosh for the great work about Quantum_Framework.
>
>  I looked at the code and have some questions.
>
>  1.  Extension standard.
>
>  In the netstack meeting, we agreed to adopt Openstack's extension
> standard. Jorge is still working on the standard draft. I'm not sure whether
> this work followed old extension mechanism or Jorge's presentation on the
> summit. One extension could be added is "attribute extension" to existing
> resources. In our use case, we need to create Portprofile and later refer it
> as a port's attribute. With current framework, we can create "Portprofile"
> as a resource through "ResourceExtension". But how does the plug-in know
> about this extension and refer the portprofile when the port is created?
>
>
>  This initial Quantum extensions merge prop essentially ports the current
> extension code that is in Nova and puts it into Quantum. I'm not completely
> sure how the current Nova extension code maps to Jorge's summit presentation
> but I think it should be pretty close. Perhaps Jorge or someone form Team
> Titan can answer that.
>
>
>
>     2. Relationship between extension and plug-in.
>
>  Extension seems be separated from the plug-in. If we want to extend
> existing plug-in, can we do it through extensions' api? How is extension
> made aware of plug-in’s existence? And how does the plug-in know the new
> resources created by extensions?
>
>
>  Since Nova doesn't have plug-ins in the same way as Quantum, I don't know
> that we've considered that relationship fully. It is a good topic for
> discussion.
>
>
>  Best,
>  Ying
>
>  _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>  Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110610/17783f54/attachment.html>