[openstack-dev] [qa] Lack of consistency in returning response from tempest clients

Christopher Yeoh cbkyeoh at gmail.com
Sat Aug 30 05:42:36 UTC 2014


On Fri, 29 Aug 2014 11:13:39 -0400
David Kranz <dkranz at redhat.com> wrote:

> On 08/29/2014 10:56 AM, Sean Dague wrote:
> > On 08/29/2014 10:19 AM, David Kranz wrote:
> >> While reviewing patches for moving response checking to the
> >> clients, I noticed that there are places where client methods do
> >> not return any value. This is usually, but not always, a delete
> >> method. IMO, every rest client method should return at least the
> >> response. Some services return just the response for delete
> >> methods and others return (resp, body). Does any one object to
> >> cleaning this up by just making all client methods return resp,
> >> body? This is mostly a change to the clients. There were only a
> >> few places where a non-delete  method was returning just a body
> >> that was used in test code.
> > Yair and I were discussing this yesterday. As the response
> > correctness checking is happening deeper in the code (and you are
> > seeing more and more people assigning the response object to _ ) my
> > feeling is Tempest clients should probably return a body obj that's
> > basically.
> >
> > class ResponseBody(dict):
> >      def __init__(self, body={}, resp=None):
> >          self.update(body)
> > 	self.resp = resp
> >
> > Then all the clients would have single return values, the body
> > would be the default thing you were accessing (which is usually
> > what you want), and the response object is accessible if needed to
> > examine headers.
> >
> > 	-Sean
> >
> Heh. I agree with that and it is along a similar line to what I
> proposed here https://review.openstack.org/#/c/106916/ but using a
> dict rather than an attribute dict. I did not propose this since it
> is such a big change. All the test code would have to be changed to
> remove the resp or _ that is now receiving the response. But I think
> we should do this before the client code is moved to tempest-lib.

+1. this would be a nice cleanup.

Chris



More information about the OpenStack-dev mailing list