[openstack-qa] Data encapsulation within Tempest

Attila Fazekas afazekas at redhat.com
Tue Jun 11 17:02:45 UTC 2013





----- 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.
 
> 	-Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
> 



More information about the openstack-qa mailing list