<p dir="ltr">Hi Jordan,</p>
<p dir="ltr">Thanks for pointing this up:-)</p>
<p dir="ltr">Your point is right for current nova situation.<br>
Nova API continues changing with small steps. The kwargs changes of tempest will help us to avoid a lot of changes in long-term.</p>
<p dir="ltr">I also am happy if getting opinions from the others.<br>
Thanks for your help and reviews anyway.</p>
<p dir="ltr">Thanks<br>
Ken Ohmichi<br>
</p>
<br><div class="gmail_quote"><div dir="ltr">2015年7月31日(金) 21:33 Jordan Pittier <<a href="mailto:jordan.pittier@scality.com">jordan.pittier@scality.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>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.</div><div><br></div><div>But I'd like to hear what other Tempest developers thing about that ? ( the topic has been mentioned in yesterday's QA meeting).</div></div><div dir="ltr"><div><br></div><div>Jordan</div></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 10, 2015 at 9:02 AM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Anne,<br>
<div><div><br>
2015-07-09 12:22 GMT+09:00 Anne Gentle <<a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>>:<br>
> On Wed, Jul 8, 2015 at 9:48 PM, GHANSHYAM MANN <<a href="mailto:ghanshyammann@gmail.com" target="_blank">ghanshyammann@gmail.com</a>><br>
> wrote:<br>
>> On Thu, Jul 9, 2015 at 9:39 AM, Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>><br>
>> wrote:<br>
>> > 2015-07-08 16:42 GMT+09:00 Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>>:<br>
>> >> 2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN <<a href="mailto:ghanshyammann@gmail.com" target="_blank">ghanshyammann@gmail.com</a>>:<br>
>> >>> On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi<br>
>> >>> <<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>> wrote:<br>
>> >>>><br>
>> >>>> By defining all parameters on each method like update_quota_set(), it<br>
>> >>>> is easy to know what parameters are available from caller/programer<br>
>> >>>> viewpoint.<br>
>> >>><br>
>> >>> I think this can be achieved with former approach also by defining all<br>
>> >>> expected param in doc string properly.<br>
>> >><br>
>> >> You are exactly right.<br>
>> >> But current service clients contain 187 methods *only for Nova* and<br>
>> >> most methods don't contain enough doc string.<br>
>> >> So my previous hope which was implied was we could avoid writing doc<br>
>> >> string with later approach.<br>
>> ><br>
>> > I am thinking it is very difficult to maintain doc string of REST APIs<br>
>> > in tempest-lib because APIs continue changing.<br>
>> > So instead of doing it, how about putting the link of official API<br>
>> > document[1] in tempest-lib and concentrating on maintaining official<br>
>> > API document?<br>
>> > OpenStack APIs are huge now and It doesn't seem smart to maintain<br>
>> > these docs at different places.<br>
>> ><br>
>><br>
>> ++, this will be great. Even API links can be provided in both class<br>
>> doc string as well as each method doc string (link to specific API).<br>
>> This will improve API ref docs quality and maintainability.<br>
><br>
><br>
> Agreed, though I also want to point you to this doc specification. We hope<br>
> it will help with the maintenance of the API docs.<br>
><br>
> <a href="https://review.openstack.org/#/c/177934/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/177934/</a><br>
><br>
> I also want Tempest maintainers to start thinking about how a diff<br>
> comparison can help with reviews of any changes to the API itself. We have a<br>
> proof of concept and need to do additional work to ensure it works for<br>
> multiple OpenStack APIs.<br>
<br>
</div></div>Thanks for your feedback,<br>
That will be a big step for improving the API docs, I also like to<br>
join for working together.<br>
<br>
Thanks<br>
<span><font color="#888888">Ken Ohmichi<br>
</font></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>