On 2014年01月14日 20:04, Ken'ichi Ohmichi wrote: > Hi, > > 2014/1/14 Alex Xu <x...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
