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

Alex Xu xuhj at linux.vnet.ibm.com
Wed Jan 15 13:32:58 UTC 2014


On 2014年01月14日 20:04, Ken'ichi Ohmichi wrote:
> Hi,
>
> 2014/1/14 Alex Xu <xuhj at linux.vnet.ibm.com>:
>> +1 for drop xml. But if we can't drop it, can we think about use
>> XMLDictSerializer instead of XmlTemplate? We spend a lot of time to maintain
>> XmlTemplate, and it make xml
>> format inconsistent(some of resouce's attribute is output as xml
>> sub-element, some of them is output as xml element's attribute, no rule for
>> them). If we just use XMLDictSerializer for all api, can we just test
>> XMLDictSerializer, not all the api?
> I like the idea that we use the same serializer for xml.
>
> Tempest contains many specific deserializers for each nova APIs, and that makes
> tempest code complex now. If using the same serializer, I guess we can reduce
> Tempest code also.
>
> In addition, can we use the same deserializer for xml request body?
I think we can, I know neutron only use XMLDictSerializer/Deserializer.
> If doing it, we will be able to generate xml response documents from jsonschema
> API definitions because of fixing the deserializing rule.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
>> On 2014年01月13日 22:38, 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
>>>
>>
>> _______________________________________________
>> 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
>
>
>




More information about the OpenStack-dev mailing list