Open Stack

On 06/11/2013 01:02 PM, Attila Fazekas wrote:
>
>
>
>
> ----- Original Message -----
>> From: "Sean Dague" <sean at dague.net>
>> To: openstack-qa at lists.openstack.org
>> Sent: Tuesday, June 11, 2013 6:13:37 PM
>> Subject: Re: [openstack-qa] Data encapsulation within Tempest
>>
>> 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
>>>> not
>>>> saving that much code. The issue is that XML behavior is different enough
>>>> from
>>>> JSON (at least in nova) that we basically have to handle everything
>>>> separately.
>>>> 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
>>>> then
>>>> to make the rest_client call) I feel that keeping them separate makes more
>>>> sense
>>>> because of all the differences it would get more complicated to handle
>>>> everything
>>>> in one class. We looked at this when we initially did the XML work, but it
>>>> ended
>>>> 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.
>>> https://github.com/openstack/tempest/commit/d42992849f95ac9a01fc73d2d6216585b6f7d174#L1R312
>>> 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.
>
> May be we need xml->json function instead of a json->xml.
> May be we need a common model, which automatically transferable to xml and json or to anything else.
>
> I hope Tal can find the real solution.

They are just really different models, at least in Nova. More power to 
anyone that can come up with a simpler separation. Just be prepared for 
some *really* weird edge cases.

	-Sean

-- 
Sean Dague
http://dague.net