Hi Ying,
1. You are right. Extension aliases would be the way plugins would advertise
the extensions they support. Right now to support multiple plugins you would
have to do something like this:
class SomePlugin :
...
def supports_extension(self, extension):
if extension.alias() in
['extension1_alias', 'extension2_alias', 'extension3_alias']:
return True
return False
This is slightly complicated so, before the merge prop we will change it to
something simpler like:
class SomePlugin:
...
self.supported_extension_aliases =
['extension1_alias', 'extension2_alias', 'extension3_alias']
2. The extension urls wouldnt sit under /v0.1/extensions by default.
/v0.1/extensions/ is intended to be a REST resource about extensions that
should contain only metadata elements of extensions.
Your extension would map directly to the main app and the url would be
/v0.1/tenants/tenantuser/portprofiles which is probably more 'restful' than
nesting portprofiles under extensions.
However, there is nothing in the framework stopping you from nesting your
extension urls under /v0.1/extensions/ or anything else. In the parent
resource that you mentioned earlier, simply change :
parent_resource = dict(member_name="tenant", collection_name="*tenants*")
to
parent_resource = dict(member_name="tenant", collection_name="*
extensions/tenants*")
Thanks,
Rajaram
On Fri, Jul 22, 2011 at 5:08 AM, Ying Liu (yinliu2) <yinl...@cisco.com>wrote:
> Hi Rajaram,****
>
> ** **
>
> I’m working on Cisco’s API extensions by using the extension framework and
> have some questions. Hope to get your help.****
>
> **1. **If our plug-in requires multiple extensions, we just need to
> list all of those aliases in supports_extension() function in the plug-in,
> right?****
>
> **2. **Through “/v0.1/extensions”, I can see the list of available
> extensions. But, when I tried to access new resources, it fails with either
> “/v0.1/extensions/tenants/tenantuser/portprofiles” or
> “/v0.1/extensions/portprofiles”. As we set up parent_resources “tenants” in
> portprofile extension, I assume the first URI should be the one we used to
> access portprofile resources. Did I miss something here?****
>
> ** **
>
> Best,****
>
> Ying****
>
> ** **
>
> ** **
>
> *From:* Rajaram Mallya [mailto:rajarammal...@gmail.com]
> *Sent:* Wednesday, July 20, 2011 10:56 AM
> *To:* Ying Liu (yinliu2)
> *Cc:* Dan Wendlandt; Somik Behera; Troy; Salvatore Orlando; Brad Hall; Ram
> Durairaj (radurair); jorge.willi...@rackspace.com; rax_network_service;
> netstack@lists.launchpad.net
>
> *Subject:* Re: Extensions and Plugins****
>
> ** **
>
> Hi Ying,****
>
> ** **
>
> We looked at your branch at
> https://code.launchpad.net/~cisco-openstack/quantum/plugin-framework.****
>
> The extension code in this branch can be easily incorporated in the
> extension framework we are proposing. ****
>
> ** **
>
> Just for demo purposes, we put your portprofile extensions into our
> extension framework :-). You can see this working at
> lp:~raxnetworking/quantum/cisco_api_extension.****
>
> The main "extensions" folder in this branch has your portprofiles extension
> code. ****
>
> Here the cisco plugin advertises that it supports the cisco portprofiles
> extension by implementing a method called "supports_extension". ****
>
> This has the advantage, as Dan mentions below, of ensuring that the
> plugin-specific cisco portprofile extension is loaded only if the cisco
> plugin is enabled.****
>
> ** **
>
> We still need some work around the framework before we raise a merge prop,
> but this should hopefully remove the confusion around how you can use the
> extension framework for plugin specific extensions.****
>
> ** **
>
> Thanks,****
>
> Rajaram ****
>
> ** **
>
> On Wed, Jul 20, 2011 at 4:34 AM, Dan Wendlandt <d...@nicira.com> wrote:****
>
> Adding main netstack list (now that we have it) to kick-off this discussion
> again. ****
>
> ** **
>
> Ying, the ability for a plugin at registration time to inform the API layer
> of a plugin-specific API extension is definitely something I see as
> critical. This API extension should be implemented by the plugin, giving
> plugins a way to expose user control over a capability that only that plugin
> implements. ****
>
> ** **
>
> At a hight-level, I think of it as: ****
>
> ** **
>
> 1) framework starts up, reads config, and loads plugin****
>
> 2) framework asks plugin what extensions that plugin will the implement. *
> ***
>
> 3) plugin provides info about each extension it supports, as well as the
> method to call (if needed) to handle calls to that API extension (e.g., if a
> new API method is introduced). This list of extension info could refer to
> "standard" extensions (i.e. those implemented by multiple extensions) or
> "plugin-specific" extensions (i.e., those only implemented by the plugin
> itself). The only difference, I suspect, would be where the python
> class(es) that define the extension are placed in the directory structure.
> ****
>
> ** **
>
> It would be helpful for me to understand if this is the same capability you
> are looking for, or if not, what additional capabilities you think we need.
> ****
>
> ** **
>
> Dan****
>
> ** **
>
> On Wed, Jul 13, 2011 at 1:50 PM, Ying Liu (yinliu2) <yinl...@cisco.com>
> wrote:****
>
> Hi Rajaram and all,****
>
> ****
>
> Thanks for the great work on extension framework.****
>
> ****
>
> Per my understanding, the standard extension mechanism is dealing with pure
> API extensions. (Please correct me if I missed something.) By “pure” API
> extension, I mean ****
>
> 1. All the extensions just function within web service layer.****
>
> 2. Application P adds extended APIs. Those extended APIs are only
> used within P’s scope.****
>
> ****
>
> I agree current extension mechanism is needed for above scenarios. ****
>
> ****
>
> However, as discussed earlier, our use case is little different. We need
> tightly coupled plug-in and API (service) extension. That is, when a new
> plug-in is developed, we define some functionalities and resources which are
> not part of quantum core. We need to expose those new resources and actions
> to users through extended REST services. Plus, those extended web services
> become part of quantum services. Any user application can use them with
> proper URL. ****
>
> ****
>
> Therefore, we need a different approach for such tightly coupled
> extensions. With current single plug-in quantum framework, the approach we
> took is directly adding new controllers for plug-in’s extended resources and
> actions. When we plug new plug-in into quantum, we anyway need to restart
> quantum service. At that time, we deploy new controllers. ****
>
> ****
>
> Currently, we use this approach to add extended REST services for our
> plug-ins. We will check in code these two days into our branch and will
> send a separate email for community’s review. If you have any questions,
> please let us know.****
>
> ****
>
> Thanks,****
>
> Ying****
>
> ****
>
> ****
>
> ****
>
> *From:* Rajaram Mallya [mailto:rajarammal...@gmail.com]
> *Sent:* Wednesday, July 13, 2011 9:52 AM
> *To:* Somik Behera
> *Cc:* Dan Wendlandt; Troy; Ying Liu (yinliu2); Salvatore Orlando; Brad
> Hall; Ram Durairaj (radurair); jorge.willi...@rackspace.com;
> rax_network_service
> *Subject:* Re:Extensions and Plugins****
>
> ****
>
> Hi Somik,****
>
> ****
>
> Thanks for the comments. Agreed that the Use Case 2 mechanism also takes
> care of Use Case 1. The only reason we had the Use Case 1 mechanism was to
> make it more convenient for plugin developers/deployers to have the plugin
> code and related extensions all in one place. But I guess the usefulness of
> this may not be that great when compared to the complexity of having to
> understand two different ways to implement extensions.****
>
> ****
>
> We can go ahead with only the standard extensions mechanism for now. If the
> Use Case 1 mechanism is deemed necessary, we can still implement it without
> causing compatibility problems for private extensions that might already be
> present at that time.****
>
> ****
>
> Thanks,****
>
> Rajaram****
>
> ****
>
> On Tue, Jul 12, 2011 at 9:52 PM, Somik Behera <so...@nicira.com> wrote:***
> *
>
> Hi Rajaram et. al.,
>
> Thanks for the work so our and the continuing work on extensions with a
> "plugin" mechanism. I agree with your use cases elucidated below that cover
> the requirements I would ask for our extensibility story to address.
>
> The one thing that I am not sure is required or I am just not clear on is
> if we require 2 separate implementation mechanisms. If we just have the
> mechanism of standard extensions as described in Use Case 2, I believe that
> would enable anybody to write private extensions as long as the extension
> plugin packager deploys the extension plugin into the correct "well known"
> location.
>
> With that said, I think if we have 2 separate mechanisms, I am fine with
> that too. Something in the implementation step that is implicit but I would
> like to restate explicitly is:
>
> - "Extensions" as mentioned in both use cases refer to API extensions only.
> - A single plugin can implement many "extension" functionality and we will
> have multiple ways for the plugin to advertise which "extensions" it is
> implementing.
>
> Otherwise, I think this proposal is good. We should customize the sample
> extension that extends everything that is "extensible" and illustrates that
> using an implementation of both use cases. That would be a very big step
> forward in enabling the eco-system to start adding functionality into
> Quantum.
>
> Thanks,
> Somik****
>
> ****
>
> On Thu, Jul 7, 2011 at 10:09 AM, Rajaram Mallya <rajarammal...@gmail.com>
> wrote:****
>
> Hi all,****
>
> ****
>
> As of right now, the extension code we ported from nova has a few
> limitations when it comes to plugins. These limitations should probably be
> addressed before we merge the extension framework into quantum. Based on the
> mails exchanged so far on this we see two distinct use cases for
> Plugin-Extensions interaction. (This is excluding the feature of dynamically
> adding extensions, which could be a separate discussion in itself.)****
>
> ****
>
> 1.Use Case: ****
>
> A plugin could have special extensions that it doesnt share with
> other plugins.****
>
> Implementation:****
>
> Plugin will contain the extensions within its plugin directory in
> a well know subfolder. ****
>
> The extension framework can find out which plugin is currently
> loaded and load the plugins extension subfolder.****
>
> ****
>
> 2. Use Case :****
>
> There are well known standard extensions that a plugin might want
> to support.****
>
> Here the APIs of the extension are standardized, but a plugin need
> not support some/any of the extensions.****
>
> Implementation:****
>
> Standard extensions exist in a configurable path.****
>
> Each standard extension defines an interface (an abstract python
> class like QuantumPluginBase).****
>
> The plugin will advertise which extensions it supports. ****
>
> The extension framework will make a compatibility check to see if
> the plugin has implemented the interface methods required for the std.
> extension.****
>
> ****
>
> Please let us know other possible use cases that you see or alternative
> ideas around implementing them. When we implement this, we can have unit
> test cases that double up as usage examples to make extension usage clear to
> plugin implementors.****
>
> ****
>
> Most of the features for extensions from Jorge's presentation are possible
> with the current extension framework. Some of them like such as extension
> headers, response extensions etc are less obvious in the framework. We are
> currently reshaping the unit tests around these to clearly demonstrate how
> these extensions can be implemented. We see only mime type extensions and
> Vendor id registries missing from the current extensions framework. Not sure
> how important these two things are right now from quantum's point of view.
> ****
>
> Based on Somik's inputs, with a README, the unit tests and some sample
> extensions that implement the features that the extension framework
> supports, I suppose we can make it fairly easy for people to implement
> extensions.****
>
> ****
>
> Thanks,
> Rajaram****
>
>
>
> ****
>
> --
> Somik Behera | Nicira Networks, Inc. | so...@nicira.com<sbeh...@nicira.com> |
> office: 650-390-6790 | cell: 512-577-6645****
>
> ****
>
>
>
> ****
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira Networks, Inc.
> www.nicira.com | www.openvswitch.org
> Sr. Product Manager
> cell: 650-906-2650
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
