Open Stack

On Thu, Feb 27, 2014 at 9:33 AM, Adrian Otto <adrian.otto at rackspace.com>wrote:

>  Doug,
>
>  On Feb 27, 2014, at 7:23 AM, Doug Hellmann <doug.hellmann at dreamhost.com>
> wrote:
>
>   On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M <noorul at noorul.com>wrote:
>
>> Michael Davies <michael at the-davies.net> writes:
>>
>> > Hi everyone,
>> >
>> > Over in "Ironic Land" we're looking at removing XML support from
>> ironic-api
>> > (i.e. https://bugs.launchpad.net/ironic/+bug/1271317)
>> >
>> > I've been looking, but I can't seem to find an easy way to modify the
>> > accepted content_types.
>> >
>> > Are there any wsgi / WSME / Pecan experts out there who can point me in
>> the
>> > right direction?
>> >
>>
>>  Also in Solum we have a use case where in we would like to have
>> pecan+wsme accept content-type application/x-yaml.
>>
>> It will be great if this can be made configurable.
>>
>  What do you want to have happen with the YAML?
>
>
>  We want to parse it into a graph of objects. It will be similar in nature
> to processing a Heat template. We will treat the resulting data structure
> as a model for generation of Heat templates, after some logic is applied to
> each object in the graph, and the relations between them.
>
>    Do you want to receive and return YAML to a bunch of API calls? We
> could add YAML protocol support to WSME to make that happen.
>
>
>  We might have a total of 3 API calls that take application/x-yaml as
> inputs in addition to the same calls also accepting application/json.
>
>    Do you want a couple of controller methods to be given a YAML parse
> result, rather than WSME objects? You could write an expose() decorator for
> Pecan in Solum. This would be a more appropriate approach if you just have
> one or two methods of the API that need YAML support.
>
>
>  Interesting. Can you think of existing implementations we could reference
> that are using this approach? What would you consider the pro/con balance
> for this?
>

I'm not aware of any OpenStack APIs that take YAML input now, but that
doesn't mean they don't exist.



>
>    Or do you want the YAML text passed in to you directly, maybe to be
> uploaded in a single controller method? You should be able to have that by
> skipping WSME and just using Pecan's expose() decorator with an appropriate
> content type, then parsing the body yourself.
>
>
>  We probably don't need to do our own parsing of the YAML text, as we
> expect that to be regular YAML. We probably don't need to parse it
> incrementally as a stream because even our most complex YAML content is not
> likely to be more than a few hundred nodes, and should fit into memory. We
> do, however need to be able to inspect and walk through a resulting data
> structure that represents the YAML content.
>
>  Would it be sensible to to have a translation shim of some sort that
> interprets the YAML into JSON, and feeds that into the existing code so
> that we would be confident there was no difference between parsing the YAML
> versus parsing equivalent JSON?
>

Is the same controller method taking both JSON and YAML at different times,
like we support now with JSON and XML?

I'm not sure I would convert YAML text to JSON text, but converting the
YAML document to the same set of data structures represented by the JSON
would make sense.

For reference:

This is the WSME decorator that handles converting incoming data to WSME
objects:
http://git.openstack.org/cgit/stackforge/wsme/tree/wsmeext/pecan.py#n46

If you want to add YAML support to WSME, you would need to add an
appropriate call to the top like we have there for JSON and XML, and then
implement a YAML protocol plugin under
http://git.openstack.org/cgit/stackforge/wsme/tree/wsme/rest like you see
there for JSON and XML.

Doug


>
>  Thanks,
>
>  Adrian
>
>
>  Doug
>
>
>
>>
>> Regards,
>> Noorul
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/54203b56/attachment.html>