Re: [Openstack] Provider Networks extension advice (was Re: [Netstack] question on get_network_details api call)
While I understand the reasons for which the RequestExtensions scheme might
be preferred over the resource extension one, I was wondering whether
assigning namespaces to attributes could be a solution to the XML
issue. This would clearly separate core attributes from extended ones.
Bob, can you share more information concerning the problem you're having
with RequestExtensions and XML?
I know it might be trivial, but I've not been following the evolution of
the code base in the past months, so I'm a bit rusty at the moment.
Salvatore
On 11 June 2012 00:44, Dan Wendlandt d...@nicira.com wrote:
Adding main openstack list, as hopefully someone there can common on
implementing Request Extensions using XML.
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.
Dan
On Fri, Jun 8, 2012 at 8:19 AM, Robert Kukura rkuk...@redhat.com wrote:
Dan, Netstackers,
I need some advice ASAP so I can proceed with the provider-networks BP
(https://blueprints.launchpad.net/quantum/+spec/provider-networks)
implementation. This BP will be implemented using a provider extension
that adds a number of optional attributes (eg. vlan tags) to the core
network resource. These attributes will be settable by and visible to
those with admin rights.
The main decision I'm looking for advice on is whether to implement this
extension as a RequestExtension or as a ResourceExtension. See the email
quoted below for details.
If implemented as a RequestExtension, these provider attributes would be
returned along with the core attributes from GET
/tenants/{tenant_id}/networks/{network_id}.json, and potentially from
all API actions that return the core attributes.
If implemented as a ResourceExtension, the provider attributes would be
accessed from a separate sub-resource, such as GET
/tenants/{tenant_id}/networks/{network_id}/provider.json.
As Dan suggested below, I think it would be preferable to extend the
core resource itself rather than define a new sub-resource. This would
mean using the RequestExtension approach. The issue with this is that I
see no way to support XML with this approach, but the ResourceExtension
approach can support both JSON and XML.
Is the RequestExtension approach preferable? Is it acceptable even if it
cannot (currently) support XML? Or is there a way to extend the XML
using a RequestExtension that I'm missing?
Thanks,
-Bob
On 06/07/2012 05:19 PM, Robert Kukura wrote:
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
Re: [Openstack] Provider Networks extension advice (was Re: [Netstack] question on get_network_details api call)
Adding main openstack list, as hopefully someone there can common on
implementing Request Extensions using XML.
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.
Dan
On Fri, Jun 8, 2012 at 8:19 AM, Robert Kukura rkuk...@redhat.com wrote:
Dan, Netstackers,
I need some advice ASAP so I can proceed with the provider-networks BP
(https://blueprints.launchpad.net/quantum/+spec/provider-networks)
implementation. This BP will be implemented using a provider extension
that adds a number of optional attributes (eg. vlan tags) to the core
network resource. These attributes will be settable by and visible to
those with admin rights.
The main decision I'm looking for advice on is whether to implement this
extension as a RequestExtension or as a ResourceExtension. See the email
quoted below for details.
If implemented as a RequestExtension, these provider attributes would be
returned along with the core attributes from GET
/tenants/{tenant_id}/networks/{network_id}.json, and potentially from
all API actions that return the core attributes.
If implemented as a ResourceExtension, the provider attributes would be
accessed from a separate sub-resource, such as GET
/tenants/{tenant_id}/networks/{network_id}/provider.json.
As Dan suggested below, I think it would be preferable to extend the
core resource itself rather than define a new sub-resource. This would
mean using the RequestExtension approach. The issue with this is that I
see no way to support XML with this approach, but the ResourceExtension
approach can support both JSON and XML.
Is the RequestExtension approach preferable? Is it acceptable even if it
cannot (currently) support XML? Or is there a way to extend the XML
using a RequestExtension that I'm missing?
Thanks,
-Bob
On 06/07/2012 05:19 PM, Robert Kukura wrote:
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
