Yeah, Sean's proposal looks great to me
On Fri, Aug 29, 2014 at 10:13 AM, David Kranz <dkr...@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.
>
> -David
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
