Open Stack

Hi Ghansyham,

Thank you for your comment.

2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN <ghanshyammann at gmail.com>:
> On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com> wrote:
>>
>> By defining all parameters on each method like update_quota_set(), it
>> is easy to know what parameters are available from caller/programer
>> viewpoint.
>
> I think this can be achieved with former approach also by defining all
> expected param in doc string properly.

You are exactly right.
But current service clients contain 187 methods *only for Nova* and
most methods don't contain enough doc string.
So my previous hope which was implied was we could avoid writing doc
string with later approach.

>> So I feel the later seems easy to use them as library methods.
>> But as the demerit, a caller cannot specify *undefined" parameters for
>> fuzzing tests.
>> Nova v2.1 API should deny a request which includes undefined
>> parameters, and Tempest will be able to test the behavior if the
>> former style.
>> So this is my concern point now.
>>
>> I tend to prefer the later(all parameters need to be defined on each
>> method) because that will be useful for callers as the above.
>> In addition, tempest-lib should be a library for implementing
>> integration tests, then fuzzing tests can be out of scope.
>> If fuzzing tests are necessary, we will be able to implement them with
>> RestClient of tempest-lib without service clients.
>
> Second approach also looks good but I prefer the first one. As you
> mentioned that fuzzy testing will not be possible with second
> approach, we should not restrict our lib functions for the same. Any
> project/test suits should be able to do API/Fuzzy testing with
> tempest-lib.
> Good example is nova v2.1 as you mentioned. Using service clients of
> lib, project (Nova) or test suits (Tempest) should be able to perform
> fuzzy testing.
>
> IMO, lib's service clients should not have any restriction on param
> list (type or number etc) to be passed from its users. Whatever
> (random param etc) is being passed that should be passed to
> corresponding projects APIs and let APIs through error or success.
>
> This can be useful when project adds new request attributes (with
> current API change guidelines like with microversion), in that case we
> do not need to change service clients. But microversion testing is not
> yet decided so this should/may not be considered a strong point?

That is a nice point.
We can avoid changing service client code with the former approach
when introducing a new attributes via a new microversion as you said.
That will be a merit when implementing tests for microversions on Tempest.

If we take the former approach, most service clients' modules contain
resource URIs and HTTP methods(PUT, POST, etc.) only as the specific
information, that seems raw methods like base RestClient class.
But as library methods, flexibility is important and the former
approach will be nice I feel now.

Thanks
Ken Ohmichi