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) <[email protected]>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:[email protected]] > *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); [email protected]; > 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 <[email protected]> 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 <[email protected]> > 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. | [email protected]<[email protected]> | > 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 : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
