Open Stack

Doug,

On Feb 27, 2014, at 7:23 AM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:

On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M <noorul at noorul.com<mailto:noorul at noorul.com>> wrote:
Michael Davies <michael at the-davies.net<mailto: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?

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?

Thanks,

Adrian


Doug



Regards,
Noorul

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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<mailto: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/d1c66285/attachment.html>