[openstack-qa] Data encapsulation within Tempest
sean at dague.net
Tue Jun 11 16:13:37 UTC 2013
On 06/11/2013 11:52 AM, Attila Fazekas wrote:
>> From: "Matthew Treinish" <mtreinish at kortar.org>
>> To: "All Things QA." <openstack-qa at lists.openstack.org>
>> Sent: Monday, June 10, 2013 4:15:15 PM
>> Subject: Re: [openstack-qa] Data encapsulation within Tempest
>> On Mon, Jun 10, 2013 at 09:18:32AM -0400, Tal Kammer wrote:
>>> I fail to see how is it close to that model today.
>>> We have a lot of duplicate code in pretty much every implementation of XML
>>> vs JSON..
>> So are you suggesting we have a uniform client and just have a
>> serializer/deserializer option for XML or JSON. That would actually end up
>> saving that much code. The issue is that XML behavior is different enough
>> JSON (at least in nova) that we basically have to handle everything
>> So there isn't actually that much to combine. It would just be the actually
>> request call which is only a few lines per request. (To format the url and
>> to make the rest_client call) I feel that keeping them separate makes more
>> because of all the differences it would get more complicated to handle
>> in one class. We looked at this when we initially did the XML work, but it
>> up being more confusing because of how XML is used in the projects.
> May be the xml_to_data/xml_to_json not smart enough.
> I suspect a smarter way can exist.
> Not just the serialization could be more generic.
> The above just a small clean up.
> Much more can be done.
> May be all of the nova API calls can fit into 1-2 normal sized python file.
No one is arguing there aren't clean ups here that could be done.
However Matt and I spent a lot of time in the Nova API on the Nova side.
The XML is not just a direct mapping from JSON. Which is why the XML API
was completely broken at Folsom-3 milestone, and why the XML code grew
the way it did in Tempest, because the thing that everyone imagines it
should be, it isn't.
We can do better, and incremental improvements are good. But blanket
statements assuming that you can factor it all out, without having
looked at the details, don't really help us more forward. :)
So cleanup patches encouraged. Refactoring for cleanliness encouraged.
I'll happily review any of that.
More information about the openstack-qa