Open Stack

On 05/07/2014 10:23 AM, Ken'ichi Ohmichi wrote:
> Hi David,
> 
> 2014-05-07 22:53 GMT+09:00 David Kranz <dkranz at redhat.com>:
>> I just looked at a patch https://review.openstack.org/#/c/90310/3 which was
>> given a -1 due to not checking that every call to list_hosts returns 200. I
>> realized that we don't have a shared understanding or policy about this. We
>> need to make sure that each api is tested to return the right response, but
>> many tests need to call multiple apis in support of the one they are
>> actually testing. It seems silly to have the caller check the response of
>> every api call. Currently there are many, if not the majority of, cases
>> where api calls are made without checking the response code. I see a few
>> possibilities:
>>
>> 1. Move all response code checking to the tempest clients. They are already
>> checking for failure codes and are now doing validation of json response and
>> headers as well. Callers would only do an explicit check if there were
>> multiple success codes possible.
>>
>> 2. Have a clear policy of when callers should check response codes and apply
>> it.
>>
>> I think the first approach has a lot of advantages. Thoughts?
> 
> Thanks for proposing this, I also prefer the first approach.
> We will be able to remove a lot of status code checks if going on
> this direction.
> It is necessary for bp/nova-api-test-inheritance tasks also.
> Current https://review.openstack.org/#/c/92536/ removes status code checks
> because some Nova v2/v3 APIs return different codes and the codes are already
> checked in client side.
> 
> but it is necessary to create a lot of patch for covering all API tests.
> So for now, I feel it is OK to skip status code checks in API tests
> only if client side checks are already implemented.
> After implementing all client validations, we can remove them of API
> tests.

Do we still have instances where we want to make a call that we know
will fail and not through the exception?

I agree there is a certain clarity in putting this down in the rest
client. I just haven't figured out if it's going to break some behavior
that we currently expect.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/c9406bed/attachment.pgp>