<div dir="ltr"><div>There are no so much messages, since first mail was published 2 weeks ago, so I don't want spend a lot of time waiting comments, which may not appear.<br><br></div><div>Btw, some questions appeared in my head related to your suggestions:)<br><br>>When user execute cmd without --os-compute-version. The nova client 
should discover the nova server >supported version. Then cmd choice the 
latest version supported both by client and server. <br><br>In that case, why X-Compute-API-Version can accept "latest" value? Also, such discovery will require extra request to API side for every client call.<br><br>>'--os-compute-version=None' can be supported, that means will return the min version of server supported.<br></div><div><br>From my point of view '--os-compute-version=None' is equal to not specified value. Maybe, it would be better to accept value "min" for os-compute-version option.<br><br><div></div><div>>The supported version can be discovered by version API (Thanks to Ken'ichi fix this):</div><br>Yeah. I saw his patch to novaclient, which adds ability to display supported microversions - <a href="https://review.openstack.org/#/c/173711/">https://review.openstack.org/#/c/173711/</a><br></div><div></div><div><br>>3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed.<br><br></div><div>Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu <span dir="ltr"><<a href="mailto:soulxu@gmail.com" target="_blank">soulxu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-04-24 17:24 GMT+08:00 Andrey Kurilin <span dir="ltr"><<a href="mailto:akurilin@mirantis.com" target="_blank">akurilin@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you for suggestions! I'll try modify patches as soon as possible.<br></div></blockquote><div><br></div></span><div>np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :)</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu <span dir="ltr"><<a href="mailto:soulxu@gmail.com" target="_blank">soulxu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Andrey for hard work on the microverison client support.<div><br></div><div>Wrote down some my thought:</div><div><br></div><div>I also agreed we will have only one endpoint 'compute'. Hope we can switch v2.1 export as '/v2' in the api-paste.conf as default very soon~</div><div><br></div><div>let's say what expected after we only have v2.1 in the world first:</div><div><br></div><div>There are two cases for use nova client.</div><div>1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova.</div><div>2. user use nova client as library. user should call the client code to discover the version and decided what version he want to use by himself.</div><div><br></div><div>For the command line, the behavior can be:</div><div><br></div><div>When user execute cmd without --os-compute-version. The nova client should discover the nova server supported version. Then cmd choice the latest version supported both by client and server. This is good for us to introduce the new feature to the user.</div><div><br></div><div>Also user can specified a version he want to by --os-compute-version.</div><div><br></div><div>'--os-compute-version=None' can be supported, that means will return the min version of server supported.</div><div><br></div><div>The supported version can be discovered by version API (Thanks to Ken'ichi fix this):</div><div>GET '/'</div><div><a href="https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25" target="_blank">https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25</a></div><div><br></div><div>But reality is the v2 and v2.1 will existed at same time.</div><div><br></div><div>So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment.</div><div><br></div><div>So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint.</div><div><br></div><div>This can be discovered by version api also.</div><div><br></div><div>GET '/v2/' will return the endpoint version info. Then we can check the version and min_version properties to know whether the api support microversion or not.</div><div><br></div><div>The behavior can be:</div><div>1. If the microversion supported, the cmd behavior is same as the description at the top of this mail<br></div><div>2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version.</div><div>3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed.</div><div><br></div><div>Hope those thoughts are helpful.</div><div><br></div><div>Looks like this need some change in current patchset also :( I know Andrey already pay lot of on this. But if we like this way, I also can give some help on the coding :)</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>Alex</div></font></span><div><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2015-04-10 19:30 GMT+08:00 Andrey Kurilin <span dir="ltr"><<a href="mailto:akurilin@mirantis.com" target="_blank">akurilin@mirantis.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div><div>Hi all!<br></div>I working on implementation of support microversions in novaclient. Patches are ready for review, but there is one opened question: what we should do with v2.1 endpoint(computev21 service type)?<br><br></div>"compute" is a default value of service type and keystone returns v2 api endpoint for it(at least in devstack), so version header will be ignored on API side.<br></div><br>On the one hand, each deployment can have it's own configuration of service catalog and endpoints, so default value of service type should be strict and support as much deployments as we can. On the other hand, dependency of service type for microversion feature is not good and end-users should not take care about choice of correct service type when they want to execute simple command. <br><br>Possible solutions:<br></div><ol><li><span lang="en"><span>leave everything as is</span><span>: </span></span>use "--service-type computev21" for each microversioned command</li><li>move default value of service type to environment variables(default value is hardcoded in novaclient code now)</li><li>add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh <a href="https://etherpad.openstack.org/p/novaclient_microversions_design" target="_blank">https://etherpad.openstack.org/p/novaclient_microversions_design</a> . Implementation is already finished - <a href="https://review.openstack.org/#/c/167577/" target="_blank">https://review.openstack.org/#/c/167577/</a> . This proposal still requires addition cli option, but compute-api-type looks more user-friendly</li></ol></div></div><div><div><div><div><div><div><div><div><br></div><div>Current implementation uses "compute" as default value for service type. Patches are pass all gates, except stable branches and ready for review:<br><ul><li><a href="https://review.openstack.org/#/c/169378/" target="_blank">https://review.openstack.org/#/c/169378/</a>  - deprecate v1.1 and remove references to v3 in code</li><li><a href="https://review.openstack.org/#/c/152569/" target="_blank">https://review.openstack.org/#/c/152569/</a>  - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with <a href="https://review.openstack.org/#/c/169292/" target="_blank">https://review.openstack.org/#/c/169292/</a> )</li><li><a href="https://review.openstack.org/#/c/167408/" target="_blank">https://review.openstack.org/#/c/167408/</a>  - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method )</li><li><a href="https://review.openstack.org/#/c/136458/" target="_blank">https://review.openstack.org/#/c/136458/</a>  - Implementation of 2.2 microversion</li></ul></div><span><font color="#888888"><div><br>-- <br><div><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</div></font></span></div></div></div></div></div></div></div></div>
<br></div></div><span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</div>