Open Stack

Hi Jordan,

Thanks for pointing this up:-)

Your point is right for current nova situation.
Nova API continues changing with small steps. The kwargs changes of tempest
will help us to avoid a lot of changes in long-term.

I also am happy if getting opinions from the others.
Thanks for your help and reviews anyway.

Thanks
Ken Ohmichi

2015年7月31日(金) 21:33 Jordan Pittier <jordan.pittier at scality.com>:

> Hi,
> So after I took a lot at Ken'ichi's recent proposed changes, I think this
> is the good approach. The kwargs approach has the good benefit of being
> generic so that if a consumer (say Nova) of the client class wants to add a
> new parameter to one of its API, it can do it without the need of updating
> the client class. This makes the client class more lightweight and should
> ease its adoption.
>
> But I'd like to hear what other Tempest developers thing about that ? (
> the topic has been mentioned in yesterday's QA meeting).
>
> Jordan
> On Fri, Jul 10, 2015 at 9:02 AM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
> wrote:
>
>> Hi Anne,
>>
>> 2015-07-09 12:22 GMT+09:00 Anne Gentle <annegentle at justwriteclick.com>:
>> > On Wed, Jul 8, 2015 at 9:48 PM, GHANSHYAM MANN <ghanshyammann at gmail.com
>> >
>> > wrote:
>> >> On Thu, Jul 9, 2015 at 9:39 AM, Ken'ichi Ohmichi <
>> ken1ohmichi at gmail.com>
>> >> wrote:
>> >> > 2015-07-08 16:42 GMT+09:00 Ken'ichi Ohmichi <ken1ohmichi at gmail.com>:
>> >> >> 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.
>> >> >
>> >> > I am thinking it is very difficult to maintain doc string of REST
>> APIs
>> >> > in tempest-lib because APIs continue changing.
>> >> > So instead of doing it, how about putting the link of official API
>> >> > document[1] in tempest-lib and concentrating on maintaining official
>> >> > API document?
>> >> > OpenStack APIs are huge now and It doesn't seem smart to maintain
>> >> > these docs at different places.
>> >> >
>> >>
>> >> ++, this will be great. Even API links can be provided in both class
>> >> doc string as well as each method doc string (link to specific API).
>> >> This will improve API ref docs quality and maintainability.
>> >
>> >
>> > Agreed, though I also want to point you to this doc specification. We
>> hope
>> > it will help with the maintenance of the API docs.
>> >
>> > https://review.openstack.org/#/c/177934/
>> >
>> > I also want Tempest maintainers to start thinking about how a diff
>> > comparison can help with reviews of any changes to the API itself. We
>> have a
>> > proof of concept and need to do additional work to ensure it works for
>> > multiple OpenStack APIs.
>>
>> Thanks for your feedback,
>> That will be a big step for improving the API docs, I also like to
>> join for working together.
>>
>> Thanks
>> Ken Ohmichi
>>
> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150802/d5972c68/attachment.html>