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

GHANSHYAM MANN ghanshyammann at gmail.com
Sat Aug 30 06:08:17 UTC 2014


+1. That will also help full for API coming up with microversion like Nova.

On Fri, Aug 29, 2014 at 11:56 PM, Sean Dague <sean at dague.net> 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
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140830/88e58a9a/attachment.html>


More information about the OpenStack-dev mailing list