Adding main openstack list, as hopefully someone there can common on implementing Request Extensions using XML.  <div><br></div><div>I personally think that Request Extensions are a cleaner approach, but it would seem silly to claim support for two serialization types, but expose some API extension that work only with one of those types.  </div>

<div><br></div><div>Dan<br><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 8:19 AM, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Dan, Netstackers,<br>
<br>
I need some advice ASAP so I can proceed with the provider-networks BP<br>
(<a href="https://blueprints.launchpad.net/quantum/+spec/provider-networks" target="_blank">https://blueprints.launchpad.net/quantum/+spec/provider-networks</a>)<br>
implementation. This BP will be implemented using a "provider" extension<br>
that adds a number of optional attributes (eg. vlan tags) to the core<br>
network resource. These attributes will be settable by and visible to<br>
those with admin rights.<br>
<br>
The main decision I'm looking for advice on is whether to implement this<br>
extension as a RequestExtension or as a ResourceExtension. See the email<br>
quoted below for details.<br>
<br>
If implemented as a RequestExtension, these provider attributes would be<br>
returned along with the core attributes from "GET<br>
/tenants/{tenant_id}/networks/{network_id}.json", and potentially from<br>
all API actions that return the core attributes.<br>
<br>
If implemented as a ResourceExtension, the provider attributes would be<br>
accessed from a separate sub-resource, such as "GET<br>
/tenants/{tenant_id}/networks/{network_id}/provider.json".<br>
<br>
As Dan suggested below, I think it would be preferable to extend the<br>
core resource itself rather than define a new sub-resource. This would<br>
mean using the RequestExtension approach. The issue with this is that I<br>
see no way to support XML with this approach, but the ResourceExtension<br>
approach can support both JSON and XML.<br>
<br>
Is the RequestExtension approach preferable? Is it acceptable even if it<br>
cannot (currently) support XML? Or is there a way to extend the XML<br>
using a RequestExtension that I'm missing?<br>
<br>
Thanks,<br>
<br>
-Bob<br>
<br>
<br>
On 06/07/2012 05:19 PM, Robert Kukura wrote:<br>
> On 06/02/2012 01:56 PM, Dan Wendlandt wrote:<br>
>> Hi Irena, Bob, Salvatore,<br>
>><br>
>> Just catching up the thread, and looping the netstack and openstack<br>
>> lists in as well, as this info is general useful in my opinion.<br>
>><br>
>> Our model with Quantum, like Nova, is that it is definitely ok to extend<br>
>> the content of a core object with additional attributes.  These<br>
>> attributes should be formatted properly as extended attribute, so that<br>
>> the "key" of the attribute is <extension-alias>:<attribute-name><br>
>><br>
>> This is done pretty commonly within Nova.  Two simple examples are:<br>
>> - nova/api/openstack/compute/contrib/scheduler_hints.py<br>
>> - nova/api/openstack/compute/contrib/extended_status.py<br>
>><br>
>> I do not believe you need to (or should) modify the view-builder code<br>
>> for the core object when you want to add an extended attribute to it.<br>
><br>
> Thanks Dan! I've now had some success implementing an extension that<br>
> creates a RequestExtension that adds extended attributes to the response<br>
> for a core resource. At least with JSON - I have not been able to figure<br>
> out how to do this for XML, if that is even possible in quantum.<br>
><br>
>>  Instead, the extension framework has you write a wsgi controller<br>
>> specific to the extension that is inserted as its own stage into the<br>
>> wsgi request and response processing pipeline.  Thus, when the request<br>
>> is passed in, your code gets a chance to parse the data, and the the<br>
>> response is passed back, your code gets a chance to add data to it.<br>
><br>
> The above description sounds more like a ResourceExtension than a<br>
> RequestExtension. A ResourceExtension introduces a new Controller,<br>
> whereas a RequestExtension just adds a handler function called by the<br>
> core's RequestExtensionController. All examples and descriptions I've<br>
> seen use ResourceExtension to introduce a new type of resource. Are you<br>
> suggesting this mechanism can also be used to extend an existing core<br>
> resource? Would this have any advantage over using a RequestExtension? I<br>
> still don't see any way a ResourceExtension could add extended<br>
> attributes into an XML response.<br>
><br>
>><br>
>> Using the Nova code as example is probably the best bet if you can find<br>
>> a good example within quantum.  Quantum's extension framework (and<br>
>> several other openstack projects) all use essentially the same model.<br>
><br>
> The nova and quantum code seem to have diverged significantly. The nova<br>
> examples use a nova.api.openstack.wsgi.extends decorator on methods of<br>
> an extension-implemented Controller to do "request extensions", but<br>
> quantum doesn't have this decorator. Also, nova uses XML templates that<br>
> are extensible, whereas the _serialization_metadata in quantum core<br>
> resources does not seem to be extensible.<br>
><br>
> At this point, quantum's RequestExtension mechanism seems able to do the<br>
> job for the provider-networks BP, assuming that a JSON-only solution is<br>
> acceptable. If both JSON and XML support are needed, then, unless I am<br>
> missing something, creating a new (sub-)resource using a<br>
> ResourceExtension (similar to the portstats extension) seems like the<br>
> only straightforward option.<br>
><br>
> -Bob<br>
><br>
>><br>
>> Dan<br>
>><br>
>><br>
>> On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a><br>
>> <mailto:<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>>> wrote:<br>
>><br>
>>     On 06/02/2012 05:02 AM, Irena Berezovsky wrote:<br>
>>     > Hi,<br>
>>     > Bob, Dan,<br>
>>     > I ran into following wiki page:<br>
>>     ><br>
>>     <a href="http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf" target="_blank">http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf</a><br>


>>     <<a href="http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf" target="_blank">http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf</a>><br>


>>     > 'port profile' is exactly what I was looking for to expose in the<br>
>>     plugin.<br>
>>     > I would like to add the port profile retrieval capability and<br>
>>     contribute the implementation.<br>
>>     ><br>
>>     > Can you please advise if there is any disagreement on getting it<br>
>>     into core API? Shall I do it via extension?<br>
>>     > Bob, seems that you are dealing with similar issues.<br>
>>     > What do you suggest?<br>
>>     ><br>
>>     > Thanks a lot,<br>
>>     > Irena<br>
>><br>
>>     Irena,<br>
>><br>
>>     I'm not sure there is any consensus around using a "network profile" for<br>
>>     this. I did see that document as well as archived discussion about<br>
>>     defining "port profile" and "network profile" as extensible collections<br>
>>     of attributes. But the existing "port profile" extension looks to be<br>
>>     Cisco-specific, and seems to serve a somewhat different purpose.<br>
>><br>
>>     My current thinking is that we'd be better off long term following the<br>
>>     lead of Nova and other projects in supporting "extension data" within<br>
>>     the existing resources instead of requiring introduction of a new<br>
>>     resource just to hold plugin-specific attributes.<br>
>><br>
>>     But, in the short term, it might make the most sense for each extension<br>
>>     just to provide its own resource extension with its attributes. That's<br>
>>     what I'm tentatively planning to do for the provider-network blueprint,<br>
>>     but would reconsider if there was consensus that either the "extension<br>
>>     data" support or a more general "network profile" should be added now.<br>
>><br>
>>     -Bob<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>> Dan Wendlandt<br>
>> Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a> <<a href="http://www.nicira.com" target="_blank">http://www.nicira.com</a>><br>
>> twitter: danwendlandt<br>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div>