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 <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 <mailto: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
