openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

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 <rkukura@xxxxxxxxxx> 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 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
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~