[openstack-dev] [nova] [rfc] drop XML from v3 API entirely

Sean Dague sean at dague.net
Tue Jan 14 15:53:38 UTC 2014

On 01/14/2014 10:50 AM, David Kranz wrote:
> On 01/14/2014 10:37 AM, Thomas Goirand wrote:
>> On 01/13/2014 10:38 PM, Sean Dague wrote:
>>> I know we've been here before, but I want to raise this again while
>>> there is still time left in icehouse.
>>> I would like to propose that the Nova v3 API removes the XML payload
>>> entirely. It adds complexity to the Nova code, and it requires
>>> duplicating all our test resources, because we need to do everything
>>> onces for JSON and once for XML. Even worse, the dual payload strategy
>>> that nova employed leaked out to a lot of other projects, so they now
>>> think maintaining 2 payloads is a good thing (which I would argue it is
>>> not).
>>> As we started talking about reducing tempest concurrency in the gate, I
>>> was starting to think a lot about what we could shed that would let us
>>> keep up a high level of testing, but bring our overall time back down.
>>> The fact that Nova provides an extremely wide testing surface makes this
>>> challenging.
>>> I think it would be a much better situation if the Nova API is a single
>>> payload type. The work on the jsonschema validation is also something
>>> where I think we could get to a fully discoverable API, which would be
>>> huge.
>>> If we never ship v3 API with XML as stable, we can deprecate it
>>> entirely, and let it die with v2 ( probably a year out ).
>>>      -Sean
>> Sean,
>> +1
>> I think this is a very good idea. Also, I'd like to point out that
>> supporting XML adds more "attack surface". In other words: we had CVEs
>> because of some nasty XML attacks, and it's always better to remove
>> useless code and complexity whenever possible.
>> Just one thing: is the AWS EC2 API using Json as well?
> No, unless they do a really good job of hiding it. And Google Compute
> Engine uses only json.

This would only be about OS native APIs, i.e. the APIs we control.

3rd party API definitions are beyond our control, and the scope of this.
Also note, none of them do the crazy thing of supporting 2 formats. :)


Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/d32294b8/attachment.pgp>

More information about the OpenStack-dev mailing list