Open Stack

----- Original Message -----
> From: "Sean Dague" <sean at dague.net>
> To: openstack-qa at lists.openstack.org
> Sent: Tuesday, June 11, 2013 8:15:58 PM
> Subject: Re: [openstack-qa] Data encapsulation within Tempest
> 
> 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.

I am afraid of you are correct, we will see.

If less than 20% is edge situation, only they should be leaved as it is,
 or juts minimally improving it.
Solving the 80% of issues is still a big gain.

The edge situations are probably happened by accident, 
 they should be reported and improved in the next API version.
 
> 	-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
>