On 06/02/2012 01:56 PM, Dan Wendlandt wrote: > 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.
Thanks Dan! I've now had some success implementing an extension that creates a RequestExtension that adds extended attributes to the response for a core resource. At least with JSON - I have not been able to figure out how to do this for XML, if that is even possible in quantum. > 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. The above description sounds more like a ResourceExtension than a RequestExtension. A ResourceExtension introduces a new Controller, whereas a RequestExtension just adds a handler function called by the core's RequestExtensionController. All examples and descriptions I've seen use ResourceExtension to introduce a new type of resource. Are you suggesting this mechanism can also be used to extend an existing core resource? Would this have any advantage over using a RequestExtension? I still don't see any way a ResourceExtension could add extended attributes into an XML response. > > 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. The nova and quantum code seem to have diverged significantly. The nova examples use a nova.api.openstack.wsgi.extends decorator on methods of an extension-implemented Controller to do "request extensions", but quantum doesn't have this decorator. Also, nova uses XML templates that are extensible, whereas the _serialization_metadata in quantum core resources does not seem to be extensible. At this point, quantum's RequestExtension mechanism seems able to do the job for the provider-networks BP, assuming that a JSON-only solution is acceptable. If both JSON and XML support are needed, then, unless I am missing something, creating a new (sub-)resource using a ResourceExtension (similar to the portstats extension) seems like the only straightforward option. -Bob > > Dan > > > On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura <rkuk...@redhat.com > <mailto: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 > > <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 <http://www.nicira.com> > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
