<div dir="ltr">Thanks, Devananda, I read the ironic spec and it almost cover all the case what I'm looking for. The only we missed in nova is return max/min version by header when nova can't process the requested version.<div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-28 15:38 GMT+08:00 Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, we enumerated the use-cases and expected behavior for all<br>
combinations of server [pre versions, older version, newer version]<br>
and client [pre versions, older version, newer version, user-specified<br>
version], in this "informational" spec:<br>
<br>
<a href="http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#proposed-change" target="_blank">http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#proposed-change</a><br>
<br>
Not all of that is implemented yet within our client, but the<br>
auto-negotiation of version is done. While our clients probably don't<br>
share any code, maybe something here can help:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/python-ironicclient/tree/ironicclient/common/http.py#n72" target="_blank">http://git.openstack.org/cgit/openstack/python-ironicclient/tree/ironicclient/common/http.py#n72</a><br>
<br>
-Deva<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Apr 27, 2015 at 2:49 AM, John Garbutt <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>> wrote:<br>
> I see these changes as really important.<br>
><br>
> We need to establish good patterns other SDKs can copy.<br>
><br>
> On 24 April 2015 at 12:05, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br>
>> 2015-04-24 18:15 GMT+08:00 Andrey Kurilin <<a href="mailto:akurilin@mirantis.com">akurilin@mirantis.com</a>>:<br>
>>> >When user execute cmd without --os-compute-version. The nova client<br>
>>> > should discover the nova server >supported version. Then cmd choice the<br>
>>> > latest version supported both by client and server.<br>
>>><br>
>>> In that case, why X-Compute-API-Version can accept "latest" value? Also,<br>
>>> such discovery will require extra request to API side for every client call.<br>
>>><br>
>><br>
>> I think it is convenient for some case. like give user more easy to try nova<br>
>> api by some code access the nova api directly. Yes, it need one more extra<br>
>> request. But if without discover, we can't ensure the client support server.<br>
>> Maybe client too old for server even didn't support the server's min<br>
>> version. For better user experience, I think it worth to discover the<br>
>> version. And we will call keystone each nova client cli call, so it is<br>
>> acceptable.<br>
><br>
> We might need to extend the API to make this easier, but I think we<br>
> need to come up with a simple and efficient pattern here.<br>
><br>
><br>
> Case 1:<br>
> Existing python-novaclient calls, now going to v2.1 API<br>
><br>
> We can look for the transitional entry of computev21, as mentioned<br>
> above, but it seems fair to assume v2.1 and v2.0 are accessed from the<br>
> same service catalog entry of "compute", by default (eventually).<br>
><br>
> Lets be optimistic about what the cloud supports, and request "latest"<br>
> version from v2.1.<br>
><br>
> If its a v2.0 only API endpoint, we will not get back a version header<br>
> with the response, we could error out if the user requested v2.x<br>
> min_version via the CLI parameters.<br>
><br>
> In most cases, we get the latest return values, and all is well.<br>
><br>
><br>
> Case 2:<br>
> User wants some info they know was added to the response in a specific<br>
> microversion<br>
><br>
> We can request "latest" and error out if we don't get a new enough<br>
> version to meet the user's min requirement.<br>
><br>
><br>
> Case 3:<br>
> Adding support for a new request added in a microversion<br>
><br>
> We could just send "latest" and assume the new functionality, then<br>
> raise an error when you get bad request (or similar), and check the<br>
> version header to see if that was the cause of the problem, so we can<br>
> say why it failed.<br>
><br>
> If its supported, everything just works.<br>
><br>
> If the user requests a specific version before it was supported, we<br>
> should error out as not supported, I guess?<br>
><br>
> In a way it would be cleaner if we had a way for the client to say<br>
> "latest but requires 2.3", so you get a bad version request if your<br>
> minimum requirement is not respected, so its much clearer than<br>
> miss-interpreting random errors that you might generate. But I guess<br>
> its not totally required here.<br>
><br>
><br>
> Would all that work? It should avoid an extra API call to discover the<br>
> specific version we have available.<br>
><br>
>>> >'--os-compute-version=None' can be supported, that means will return the<br>
>>> > min version of server supported.<br>
>>><br>
>>> From my point of view '--os-compute-version=None' is equal to not<br>
>>> specified value. Maybe, it would be better to accept value "min" for<br>
>>> os-compute-version option.<br>
>><br>
>> I think '--os-compute-version=None' means not specified version request<br>
>> header when send api request to server. The server behavior is if there<br>
>> isn't value specified, the min version will be used.<br>
><br>
> --os-compte-version=v2 means no version specified I guess?<br>
><br>
> Can we go back to the use cases here please?<br>
> What do the users need here and why?<br>
><br>
><br>
>>> >3. if the microversion non-supported, but user call cmd with<br>
>>> > --os-compute-version, this should return failed.<br>
>>><br>
>>> Imo, it should be implemented on API side(return BadRequest when<br>
>>> X-Compute-API-Version header is presented in V2)<br>
><br>
> V2 is already deployed now, and doesn't do that.<br>
><br>
> No matter what happens we need to fix that.<br>
>><br>
>> Emm.... I'm not sure. Because GET '/v2/' already can be used to discover<br>
>> microversion support or not. Sounds like add another way to support<br>
>> discover? And v2 api didn't return fault with some extra header, that sounds<br>
>> like behavior and back-incompatible change.<br>
><br>
> -1<br>
><br>
> We should not use the URL to detect the version.<br>
> We have other ways to do that for a good reason.<br>
><br>
> Thanks,<br>
> John<br>
><br>
><br>
><br>
>>> On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 2015-04-24 17:24 GMT+08:00 Andrey Kurilin <<a href="mailto:akurilin@mirantis.com">akurilin@mirantis.com</a>>:<br>
>>>>><br>
>>>>> Thank you for suggestions! I'll try modify patches as soon as possible.<br>
>>>><br>
>>>><br>
>>>> np, it's better waiting for more comment before you begin to update the<br>
>>>> code first. avoid you need rework again I think :)<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Thanks Andrey for hard work on the microverison client support.<br>
>>>>>><br>
>>>>>> Wrote down some my thought:<br>
>>>>>><br>
>>>>>> I also agreed we will have only one endpoint 'compute'. Hope we can<br>
>>>>>> switch v2.1 export as '/v2' in the api-paste.conf as default very soon~<br>
>>>>>><br>
>>>>>> let's say what expected after we only have v2.1 in the world first:<br>
>>>>>><br>
>>>>>> There are two cases for use nova client.<br>
>>>>>> 1. user use nova client command line. I think command line should<br>
>>>>>> support version discover. Provide most convenient way let the user try nova.<br>
>>>>>> 2. user use nova client as library. user should call the client code to<br>
>>>>>> discover the version and decided what version he want to use by himself.<br>
>>>>>><br>
>>>>>> For the command line, the behavior can be:<br>
>>>>>><br>
>>>>>> When user execute cmd without --os-compute-version. The nova client<br>
>>>>>> should discover the nova server supported version. Then cmd choice the<br>
>>>>>> latest version supported both by client and server. This is good for us to<br>
>>>>>> introduce the new feature to the user.<br>
>>>>>><br>
>>>>>> Also user can specified a version he want to by --os-compute-version.<br>
>>>>>><br>
>>>>>> '--os-compute-version=None' can be supported, that means will return<br>
>>>>>> the min version of server supported.<br>
>>>>>><br>
>>>>>> The supported version can be discovered by version API (Thanks to<br>
>>>>>> Ken'ichi fix this):<br>
>>>>>> GET '/'<br>
>>>>>><br>
>>>>>> <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><br>
>>>>>><br>
>>>>>> But reality is the v2 and v2.1 will existed at same time.<br>
>>>>>><br>
>>>>>> So the v2 or v2.1 code both can run under the endpoint 'compute' with<br>
>>>>>> url '/v2'. It depend on the admin's deployment.<br>
>>>>>><br>
>>>>>> So I think the cmd also can discover whether the api supported<br>
>>>>>> microversion under the 'compute' endpoint.<br>
>>>>>><br>
>>>>>> This can be discovered by version api also.<br>
>>>>>><br>
>>>>>> GET '/v2/' will return the endpoint version info. Then we can check the<br>
>>>>>> version and min_version properties to know whether the api support<br>
>>>>>> microversion or not.<br>
>>>>>><br>
>>>>>> The behavior can be:<br>
>>>>>> 1. If the microversion supported, the cmd behavior is same as the<br>
>>>>>> description at the top of this mail<br>
>>>>>> 2. If the microversion non-supported, user call cmd without<br>
>>>>>> --os-compute-version, we use the min version.<br>
>>>>>> 3. if the microversion non-supported, but user call cmd with<br>
>>>>>> --os-compute-version, this should return failed.<br>
>>>>>><br>
>>>>>> Hope those thoughts are helpful.<br>
>>>>>><br>
>>>>>> Looks like this need some change in current patchset also :( I know<br>
>>>>>> Andrey already pay lot of on this. But if we like this way, I also can give<br>
>>>>>> some help on the coding :)<br>
>>>>>><br>
>>>>>> Thanks<br>
>>>>>> Alex<br>
>>>>>><br>
>>>>>><br>
>>>>>> 2015-04-10 19:30 GMT+08:00 Andrey Kurilin <<a href="mailto:akurilin@mirantis.com">akurilin@mirantis.com</a>>:<br>
>>>>>>><br>
>>>>>>> Hi all!<br>
>>>>>>> I working on implementation of support microversions in novaclient.<br>
>>>>>>> Patches are ready for review, but there is one opened question: what we<br>
>>>>>>> should do with v2.1 endpoint(computev21 service type)?<br>
>>>>>>><br>
>>>>>>> "compute" is a default value of service type and keystone returns v2<br>
>>>>>>> api endpoint for it(at least in devstack), so version header will be ignored<br>
>>>>>>> on API side.<br>
>>>>>>><br>
>>>>>>> On the one hand, each deployment can have it's own configuration of<br>
>>>>>>> service catalog and endpoints, so default value of service type should be<br>
>>>>>>> strict and support as much deployments as we can. On the other hand,<br>
>>>>>>> dependency of service type for microversion feature is not good and<br>
>>>>>>> end-users should not take care about choice of correct service type when<br>
>>>>>>> they want to execute simple command.<br>
>>>>>>><br>
>>>>>>> Possible solutions:<br>
>>>>>>><br>
>>>>>>> leave everything as is: use "--service-type computev21" for each<br>
>>>>>>> microversioned command<br>
>>>>>>> move default value of service type to environment variables(default<br>
>>>>>>> value is hardcoded in novaclient code now)<br>
>>>>>>> add additional option --compute-api-type. Proposed etherpad by<br>
>>>>>>> Christopher Yeoh<br>
>>>>>>> <a href="https://etherpad.openstack.org/p/novaclient_microversions_design" target="_blank">https://etherpad.openstack.org/p/novaclient_microversions_design</a> .<br>
>>>>>>> Implementation is already finished -<br>
>>>>>>> <a href="https://review.openstack.org/#/c/167577/" target="_blank">https://review.openstack.org/#/c/167577/</a> . This proposal still requires<br>
>>>>>>> addition cli option, but compute-api-type looks more user-friendly<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Current implementation uses "compute" as default value for service<br>
>>>>>>> type. Patches are pass all gates, except stable branches and ready for<br>
>>>>>>> review:<br>
>>>>>>><br>
>>>>>>> <a href="https://review.openstack.org/#/c/169378/" target="_blank">https://review.openstack.org/#/c/169378/</a> - deprecate v1.1 and remove<br>
>>>>>>> references to v3 in code<br>
>>>>>>> <a href="https://review.openstack.org/#/c/152569/" target="_blank">https://review.openstack.org/#/c/152569/</a> - Implements 'microversions'<br>
>>>>>>> api type - Part 1 (usage of<br>
>>>>>>> nova.api.openstack.api_version_request:APIVersionRequest class with<br>
>>>>>>> <a href="https://review.openstack.org/#/c/169292/" target="_blank">https://review.openstack.org/#/c/169292/</a> )<br>
>>>>>>> <a href="https://review.openstack.org/#/c/167408/" target="_blank">https://review.openstack.org/#/c/167408/</a> - Implements 'microversions'<br>
>>>>>>> api type - Part 2 (adds new decorators and substitution mechanism using<br>
>>>>>>> nova.api.openstack.versioned_method )<br>
>>>>>>> <a href="https://review.openstack.org/#/c/136458/" target="_blank">https://review.openstack.org/#/c/136458/</a> - Implementation of 2.2<br>
>>>>>>> microversion<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Best regards,<br>
>>>>>>> Andrey Kurilin.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> __________________________________________________________________________<br>
>>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>>> Unsubscribe:<br>
>>>>>>> <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>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> __________________________________________________________________________<br>
>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <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>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Best regards,<br>
>>>>> Andrey Kurilin.<br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <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>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <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>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Best regards,<br>
>>> Andrey Kurilin.<br>
>>><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>
>><br>
>><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>
><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>
__________________________________________________________________________<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>
</div></div></blockquote></div><br></div></div></div>