Open Stack

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?
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