Hi Irena, Our pretty wimpy existing developer docs cover extensions: http://wiki.openstack.org/QuantumDevelopment
Would be great if you and others could help expand these docs as you identify gaps. Thanks, Dan On Sat, Jun 2, 2012 at 12:16 PM, Irena Berezovsky <ire...@mellanox.com>wrote: > Dan, thank you very much for pointing to nova examples.**** > > Following these examples and also > http://wiki.openstack.org/WritingRequestExtensions guidelines I > understand how to add extension to nova, but still has questions how to add > it to Quantum.**** > > Nova extensions make use of nova.api.openstack.extensions module and > Quantum has its own implementation.**** > > Can you please point to some documentation regarding writing Quantum > extensions? **** > > Thanks a lot,**** > > Irena**** > > ** ** > > *From:* Dan Wendlandt [mailto:d...@nicira.com] > *Sent:* Saturday, June 02, 2012 8:57 PM > *To:* Robert Kukura > *Cc:* Irena Berezovsky; Salvatore Orlando; netst...@lists.launchpad.net; > openstack@lists.launchpad.net > > *Subject:* Re: [Netstack] question on get_network_details api call**** > > ** ** > > Hi Irena, Bob, Salvatore, **** > > ** ** > > Just catching up the thread, and looping the netstack and openstack lists > in as well, as this info is general useful in my opinion. **** > > ** ** > > Our model with Quantum, like Nova, is that it is definitely ok to extend > the content of a core object with additional attributes. These attributes > should be formatted properly as extended attribute, so that the "key" of > the attribute is <extension-alias>:<attribute-name> **** > > ** ** > > This is done pretty commonly within Nova. Two simple examples are: **** > > - nova/api/openstack/compute/contrib/scheduler_hints.py**** > > - nova/api/openstack/compute/contrib/extended_status.py**** > > ** ** > > I do not believe you need to (or should) modify the view-builder code for > the core object when you want to add an extended attribute to it. Instead, > the extension framework has you write a wsgi controller specific to the > extension that is inserted as its own stage into the wsgi request and > response processing pipeline. Thus, when the request is passed in, your > code gets a chance to parse the data, and the the response is passed back, > your code gets a chance to add data to it. **** > > ** ** > > Using the Nova code as example is probably the best bet if you can find a > good example within quantum. Quantum's extension framework (and several > other openstack projects) all use essentially the same model. **** > > ** ** > > Dan**** > > ** ** > > ** ** > > On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura <rkuk...@redhat.com> wrote:* > *** > > On 06/02/2012 05:02 AM, Irena Berezovsky wrote: > > Hi, > > Bob, Dan, > > I ran into following wiki page: > > > http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf > > 'port profile' is exactly what I was looking for to expose in the plugin. > > I would like to add the port profile retrieval capability and contribute > the implementation. > > > > Can you please advise if there is any disagreement on getting it into > core API? Shall I do it via extension? > > Bob, seems that you are dealing with similar issues. > > What do you suggest? > > > > Thanks a lot, > > Irena**** > > Irena, > > I'm not sure there is any consensus around using a "network profile" for > this. I did see that document as well as archived discussion about > defining "port profile" and "network profile" as extensible collections > of attributes. But the existing "port profile" extension looks to be > Cisco-specific, and seems to serve a somewhat different purpose. > > My current thinking is that we'd be better off long term following the > lead of Nova and other projects in supporting "extension data" within > the existing resources instead of requiring introduction of a new > resource just to hold plugin-specific attributes. > > But, in the short term, it might make the most sense for each extension > just to provide its own resource extension with its attributes. That's > what I'm tentatively planning to do for the provider-network blueprint, > but would reconsider if there was consensus that either the "extension > data" support or a more general "network profile" should be added now. > > -Bob**** > > > > **** > > ** ** > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt **** > > Nicira, Inc: www.nicira.com**** > > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > > ** ** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
