openstack team mailing list archive

[Robert Kukura <rkukura@xxxxxxxxxx>]

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 <rkukura@xxxxxxxxxx
> <mailto:rkukura@xxxxxxxxxx>> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>