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
