openstack team mailing list archive

[Salvatore Orlando <salv.orlando@xxxxxxxxx>]

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