Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
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. 2015-04-28 15:38 GMT+08:00 Devananda van der Veen devananda@gmail.com: FWIW, we enumerated the use-cases and expected behavior for all combinations of server [pre versions, older version, newer version] and client [pre versions, older version, newer version, user-specified version], in this informational spec: http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#proposed-change Not all of that is implemented yet within our client, but the auto-negotiation of version is done. While our clients probably don't share any code, maybe something here can help: http://git.openstack.org/cgit/openstack/python-ironicclient/tree/ironicclient/common/http.py#n72 -Deva On Mon, Apr 27, 2015 at 2:49 AM, John Garbutt j...@johngarbutt.com wrote: I see these changes as really important. We need to establish good patterns other SDKs can copy. On 24 April 2015 at 12:05, Alex Xu sou...@gmail.com wrote: 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. We might need to extend the API to make this easier, but I think we need to come up with a simple and efficient pattern here. Case 1: Existing python-novaclient calls, now going to v2.1 API We can look for the transitional entry of computev21, as mentioned above, but it seems fair to assume v2.1 and v2.0 are accessed from the same service catalog entry of compute, by default (eventually). Lets be optimistic about what the cloud supports, and request latest version from v2.1. If its a v2.0 only API endpoint, we will not get back a version header with the response, we could error out if the user requested v2.x min_version via the CLI parameters. In most cases, we get the latest return values, and all is well. Case 2: User wants some info they know was added to the response in a specific microversion We can request latest and error out if we don't get a new enough version to meet the user's min requirement. Case 3: Adding support for a new request added in a microversion We could just send latest and assume the new functionality, then raise an error when you get bad request (or similar), and check the version header to see if that was the cause of the problem, so we can say why it failed. If its supported, everything just works. If the user requests a specific version before it was supported, we should error out as not supported, I guess? In a way it would be cleaner if we had a way for the client to say latest but requires 2.3, so you get a bad version request if your minimum requirement is not respected, so its much clearer than miss-interpreting random errors that you might generate. But I guess its not totally required here. Would all that work? It should avoid an extra API call to discover the specific version we have available. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. --os-compte-version=v2 means no version specified I guess? Can we go back to the use cases here please? What do the users need here and why? 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) V2 is already deployed now, and doesn't do that. No matter what happens we need to fix that. Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
FWIW, we enumerated the use-cases and expected behavior for all combinations of server [pre versions, older version, newer version] and client [pre versions, older version, newer version, user-specified version], in this informational spec: http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#proposed-change Not all of that is implemented yet within our client, but the auto-negotiation of version is done. While our clients probably don't share any code, maybe something here can help: http://git.openstack.org/cgit/openstack/python-ironicclient/tree/ironicclient/common/http.py#n72 -Deva On Mon, Apr 27, 2015 at 2:49 AM, John Garbutt j...@johngarbutt.com wrote: I see these changes as really important. We need to establish good patterns other SDKs can copy. On 24 April 2015 at 12:05, Alex Xu sou...@gmail.com wrote: 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. We might need to extend the API to make this easier, but I think we need to come up with a simple and efficient pattern here. Case 1: Existing python-novaclient calls, now going to v2.1 API We can look for the transitional entry of computev21, as mentioned above, but it seems fair to assume v2.1 and v2.0 are accessed from the same service catalog entry of compute, by default (eventually). Lets be optimistic about what the cloud supports, and request latest version from v2.1. If its a v2.0 only API endpoint, we will not get back a version header with the response, we could error out if the user requested v2.x min_version via the CLI parameters. In most cases, we get the latest return values, and all is well. Case 2: User wants some info they know was added to the response in a specific microversion We can request latest and error out if we don't get a new enough version to meet the user's min requirement. Case 3: Adding support for a new request added in a microversion We could just send latest and assume the new functionality, then raise an error when you get bad request (or similar), and check the version header to see if that was the cause of the problem, so we can say why it failed. If its supported, everything just works. If the user requests a specific version before it was supported, we should error out as not supported, I guess? In a way it would be cleaner if we had a way for the client to say latest but requires 2.3, so you get a bad version request if your minimum requirement is not respected, so its much clearer than miss-interpreting random errors that you might generate. But I guess its not totally required here. Would all that work? It should avoid an extra API call to discover the specific version we have available. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. --os-compte-version=v2 means no version specified I guess? Can we go back to the use cases here please? What do the users need here and why? 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) V2 is already deployed now, and doesn't do that. No matter what happens we need to fix that. Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion support or not. Sounds like add another way to support discover? And v2 api didn't return fault with some extra header, that sounds like behavior and back-incompatible change. -1 We should not use the URL to detect the version. We have other ways to do that for a good reason. Thanks, John On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote: 2015-04-24 17:24 GMT+08:00 Andrey
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
2015-04-27 17:49 GMT+08:00 John Garbutt j...@johngarbutt.com: I see these changes as really important. We need to establish good patterns other SDKs can copy. On 24 April 2015 at 12:05, Alex Xu sou...@gmail.com wrote: 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. We might need to extend the API to make this easier, but I think we need to come up with a simple and efficient pattern here. Case 1: Existing python-novaclient calls, now going to v2.1 API We can look for the transitional entry of computev21, as mentioned above, but it seems fair to assume v2.1 and v2.0 are accessed from the same service catalog entry of compute, by default (eventually). Lets be optimistic about what the cloud supports, and request latest version from v2.1. If its a v2.0 only API endpoint, we will not get back a version header with the response, we could error out if the user requested v2.x min_version via the CLI parameters. In most cases, we get the latest return values, and all is well. Case 2: User wants some info they know was added to the response in a specific microversion We can request latest and error out if we don't get a new enough version to meet the user's min requirement. Case 3: Adding support for a new request added in a microversion We could just send latest and assume the new functionality, then raise an error when you get bad request (or similar), and check the version header to see if that was the cause of the problem, so we can say why it failed. If its supported, everything just works. If the user requests a specific version before it was supported, we should error out as not supported, I guess? In a way it would be cleaner if we had a way for the client to say latest but requires 2.3, so you get a bad version request if your minimum requirement is not respected, so its much clearer than miss-interpreting random errors that you might generate. But I guess its not totally required here. Would all that work? It should avoid an extra API call to discover the specific version we have available. Another thought is send the client's latest version to the servers. Microversion support back-incompatible change, for the case old client vs new servers, will get more chance to failure. If the client's lastest version didn't supported, we can return error to the user. And I registered a bug few days ago, we can return some header to show supported version in server when the request failed. https://bugs.launchpad.net/nova/+bug/1443494 then we can get better error message to the user. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. --os-compte-version=v2 means no version specified I guess? Can we go back to the use cases here please? What do the users need here and why? 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) V2 is already deployed now, and doesn't do that. No matter what happens we need to fix that. Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion support or not. Sounds like add another way to support discover? And v2 api didn't return fault with some extra header, that sounds like behavior and back-incompatible change. -1 We should not use the URL to detect the version. We have other ways to do that for a good reason. Sorry, I didn't describe clearly at here. I'm not mean use URL to detect the version at here. I mean GET '/' will get response like this
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
2015-04-28 15:22 GMT+08:00 Alex Xu sou...@gmail.com: 2015-04-27 17:49 GMT+08:00 John Garbutt j...@johngarbutt.com: I see these changes as really important. We need to establish good patterns other SDKs can copy. On 24 April 2015 at 12:05, Alex Xu sou...@gmail.com wrote: 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. We might need to extend the API to make this easier, but I think we need to come up with a simple and efficient pattern here. Case 1: Existing python-novaclient calls, now going to v2.1 API We can look for the transitional entry of computev21, as mentioned above, but it seems fair to assume v2.1 and v2.0 are accessed from the same service catalog entry of compute, by default (eventually). Lets be optimistic about what the cloud supports, and request latest version from v2.1. If its a v2.0 only API endpoint, we will not get back a version header with the response, we could error out if the user requested v2.x min_version via the CLI parameters. In most cases, we get the latest return values, and all is well. Case 2: User wants some info they know was added to the response in a specific microversion We can request latest and error out if we don't get a new enough version to meet the user's min requirement. Case 3: Adding support for a new request added in a microversion We could just send latest and assume the new functionality, then raise an error when you get bad request (or similar), and check the version header to see if that was the cause of the problem, so we can say why it failed. If its supported, everything just works. If the user requests a specific version before it was supported, we should error out as not supported, I guess? In a way it would be cleaner if we had a way for the client to say latest but requires 2.3, so you get a bad version request if your minimum requirement is not respected, so its much clearer than miss-interpreting random errors that you might generate. But I guess its not totally required here. Would all that work? It should avoid an extra API call to discover the specific version we have available. Another thought is send the client's latest version to the servers. Microversion support back-incompatible change, for the case old client vs new servers, will get more chance to failure. If the client's lastest version didn't supported, we can return error to the user. And I registered a bug few days ago, we can return some header to show supported version in server when the request failed. https://bugs.launchpad.net/nova/+bug/1443494 then we can get better error message to the user. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. --os-compte-version=v2 means no version specified I guess? Can we go back to the use cases here please? What do the users need here and why? 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) V2 is already deployed now, and doesn't do that. No matter what happens we need to fix that. Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion support or not. Sounds like add another way to support discover? And v2 api didn't return fault with some extra header, that sounds like behavior and back-incompatible change. -1 We should not use the URL to detect the version. We have other ways to do that for a good reason. Sorry, I didn't describe clearly at here. I'm not mean use URL to detect the version at here. I mean GET '/' will get response like this
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
I see these changes as really important. We need to establish good patterns other SDKs can copy. On 24 April 2015 at 12:05, Alex Xu sou...@gmail.com wrote: 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. We might need to extend the API to make this easier, but I think we need to come up with a simple and efficient pattern here. Case 1: Existing python-novaclient calls, now going to v2.1 API We can look for the transitional entry of computev21, as mentioned above, but it seems fair to assume v2.1 and v2.0 are accessed from the same service catalog entry of compute, by default (eventually). Lets be optimistic about what the cloud supports, and request latest version from v2.1. If its a v2.0 only API endpoint, we will not get back a version header with the response, we could error out if the user requested v2.x min_version via the CLI parameters. In most cases, we get the latest return values, and all is well. Case 2: User wants some info they know was added to the response in a specific microversion We can request latest and error out if we don't get a new enough version to meet the user's min requirement. Case 3: Adding support for a new request added in a microversion We could just send latest and assume the new functionality, then raise an error when you get bad request (or similar), and check the version header to see if that was the cause of the problem, so we can say why it failed. If its supported, everything just works. If the user requests a specific version before it was supported, we should error out as not supported, I guess? In a way it would be cleaner if we had a way for the client to say latest but requires 2.3, so you get a bad version request if your minimum requirement is not respected, so its much clearer than miss-interpreting random errors that you might generate. But I guess its not totally required here. Would all that work? It should avoid an extra API call to discover the specific version we have available. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. --os-compte-version=v2 means no version specified I guess? Can we go back to the use cases here please? What do the users need here and why? 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) V2 is already deployed now, and doesn't do that. No matter what happens we need to fix that. Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion support or not. Sounds like add another way to support discover? And v2 api didn't return fault with some extra header, that sounds like behavior and back-incompatible change. -1 We should not use the URL to detect the version. We have other ways to do that for a good reason. Thanks, John On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote: 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Thank you for suggestions! I'll try modify patches as soon as possible. np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :) On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover.
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
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. Btw, some questions appeared in my head related to your suggestions:) 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. 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. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): Yeah. I saw his patch to novaclient, which adds ability to display supported microversions - https://review.openstack.org/#/c/173711/ 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote: 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Thank you for suggestions! I'll try modify patches as soon as possible. np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :) On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 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. For the command line, the behavior can be: 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. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. 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. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. 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 :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! 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)? 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. 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. Possible solutions: 1. leave everything as is: use --service-type
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Thank you for suggestions! I'll try modify patches as soon as possible. np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :) On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 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. For the command line, the behavior can be: 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. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. 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. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. 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 :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! 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)? 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. 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. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: - https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code - https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) - https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) - https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin.
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Thank you for suggestions! I'll try modify patches as soon as possible. On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 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. For the command line, the behavior can be: 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. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. 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. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. 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 :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! 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)? 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. 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. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: - https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code - https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) - https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) - https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: 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. Sorry for that, I also replied too late, but let's see what we can help you more. Btw, some questions appeared in my head related to your suggestions:) 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. 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. I think it is convenient for some case. like give user more easy to try nova api by some code access the nova api directly. Yes, it need one more extra request. But if without discover, we can't ensure the client support server. Maybe client too old for server even didn't support the server's min version. For better user experience, I think it worth to discover the version. And we will call keystone each nova client cli call, so it is acceptable. '--os-compute-version=None' can be supported, that means will return the min version of server supported. 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. I think '--os-compute-version=None' means not specified version request header when send api request to server. The server behavior is if there isn't value specified, the min version will be used. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): Yeah. I saw his patch to novaclient, which adds ability to display supported microversions - https://review.openstack.org/#/c/173711/ Yea 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) Emm I'm not sure. Because GET '/v2/' already can be used to discover microversion support or not. Sounds like add another way to support discover? And v2 api didn't return fault with some extra header, that sounds like behavior and back-incompatible change. On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote: 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Thank you for suggestions! I'll try modify patches as soon as possible. np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :) On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 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. For the command line, the behavior can be: 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. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. 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. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful.
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: 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~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 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. For the command line, the behavior can be: 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. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. 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. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. 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 :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! 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)? 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. 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. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: - https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code - https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) - https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) - https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
On Tue, Apr 21, 2015 at 1:27 PM, Chris Friesen chris.frie...@windriver.com wrote: On 04/21/2015 11:35 AM, Hayes, Graham wrote: From: Jay Pipes [jaypi...@gmail.com] The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Yes - please don't add a flag to the cli (or the python bindings for that matter) Isn't a cli flag exactly what Jay was describing? It is, it already exists, it just needs to be made to properly recognize the required version strings, which is what Jay was suggesting. This should be done via discovery. If a call requires a micro-version that is not deployed - return an error. I haven't had the pleasure(?) of needing to do this, but wouldn't you need to know what API versions are available before you try to do some task? (In order to know what actions are available, or what parameters to expect to be returned.) When a user needs to know much more about the API than this is the one that does Whiz-Bang Feature that I want then we've failed. Also, many users aren't probably going to care about API microversions, more likely to care that GWclient 2.1.2 is the version they need to use Whiz-Bang since that's what they'll have control over. As I understand it, Jay's proposal is that if you don't specify a version you get the default (currently version 2, I think), if you do specify a version you get that version, and if you specify latest then you get the most recent version that the server knows about. The way we've been headed in other discovery implementations is to negotiate the highest compatible version between the client and server unless a specific version requested. What happens in the client will of course be client-specific, but as a user I would hope that it either makes a best effort to fail gracefully or make a lot of noise that includes a clue as to why it failed. dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
On 04/21/2015 11:35 AM, Hayes, Graham wrote: From: Jay Pipes [jaypi...@gmail.com] The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Yes - please don't add a flag to the cli (or the python bindings for that matter) Isn't a cli flag exactly what Jay was describing? Speaking as someone who spends a lot of time interaction with different clouds, based on different versions of OpenStack and develops on top of tip of master clouds - the thought of trying to remember what micro versions are enabled on the cloud I am currently testing / working on is terrifying. This should be done via discovery. If a call requires a micro-version that is not deployed - return an error. I haven't had the pleasure(?) of needing to do this, but wouldn't you need to know what API versions are available before you try to do some task? (In order to know what actions are available, or what parameters to expect to be returned.) As I understand it, Jay's proposal is that if you don't specify a version you get the default (currently version 2, I think), if you do specify a version you get that version, and if you specify latest then you get the most recent version that the server knows about. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
On 04/20/2015 06:30 PM, Claudiu Belu wrote: Hello, So, AFAIK, there is currently a problem with this. If you make a request for, let's say v2.2 microversion, you will want to execute: nova --os-compute-api-version 2.2 keypair-list But, from my experience, that does not work as expected. Instead of the plugins/v3/ module, it is executed the old contrib/ module, which is not expected. (Also, I've checked, the request header contains X-OpenStack-Compute-API-Version, it is ignored) The only way to get it right (at least in devstack) is to execute: nova --service-type computev21 --os-compute-api-version 2.2 keypair-list So, if I understand Jay correctly, only service-type 'compute' should exist and if any microversion is requested, that particular microversion should be executed. Currently, it doesn't behave like this... so.. Houston, we have a problem. :) Best regards, Claudiu From: Jay Pipes [jaypi...@gmail.com] Sent: Sunday, April 19, 2015 3:45 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side Andrey, thanks for posing these important questions. My thoughts inline. On 04/10/2015 07:30 AM, Andrey Kurilin wrote: Hi all! 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)? 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. 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. Correct. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command It was a mistake to put any version information in *any* of the service types. The service type should be compute and only compute. The version negotiation should be handled entirely separately via the X-OpenStack-Compute-API-Version HTTP header sent from the client. 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) I don't see any reason to do that, no. 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly -1. There should be no additional option. The API microversion should be negotiated via the X-OpenStack-Compute-API-Version HTTP header and only via that. The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Best, -jay Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: * https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code * https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) * https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) * https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Yes - please don't add a flag to the cli (or the python bindings for that matter) Speaking as someone who spends a lot of time interaction with different clouds, based on different versions of OpenStack and develops on top of tip of master clouds - the thought of trying to remember what micro versions
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Hello, So, AFAIK, there is currently a problem with this. If you make a request for, let's say v2.2 microversion, you will want to execute: nova --os-compute-api-version 2.2 keypair-list But, from my experience, that does not work as expected. Instead of the plugins/v3/ module, it is executed the old contrib/ module, which is not expected. (Also, I've checked, the request header contains X-OpenStack-Compute-API-Version, it is ignored) The only way to get it right (at least in devstack) is to execute: nova --service-type computev21 --os-compute-api-version 2.2 keypair-list So, if I understand Jay correctly, only service-type 'compute' should exist and if any microversion is requested, that particular microversion should be executed. Currently, it doesn't behave like this... so.. Houston, we have a problem. :) Best regards, Claudiu From: Jay Pipes [jaypi...@gmail.com] Sent: Sunday, April 19, 2015 3:45 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side Andrey, thanks for posing these important questions. My thoughts inline. On 04/10/2015 07:30 AM, Andrey Kurilin wrote: Hi all! 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)? 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. 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. Correct. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command It was a mistake to put any version information in *any* of the service types. The service type should be compute and only compute. The version negotiation should be handled entirely separately via the X-OpenStack-Compute-API-Version HTTP header sent from the client. 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) I don't see any reason to do that, no. 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly -1. There should be no additional option. The API microversion should be negotiated via the X-OpenStack-Compute-API-Version HTTP header and only via that. The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Best, -jay Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: * https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code * https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) * https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) * https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Andrey, thanks for posing these important questions. My thoughts inline. On 04/10/2015 07:30 AM, Andrey Kurilin wrote: Hi all! 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)? 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. 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. Correct. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command It was a mistake to put any version information in *any* of the service types. The service type should be compute and only compute. The version negotiation should be handled entirely separately via the X-OpenStack-Compute-API-Version HTTP header sent from the client. 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) I don't see any reason to do that, no. 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly -1. There should be no additional option. The API microversion should be negotiated via the X-OpenStack-Compute-API-Version HTTP header and only via that. The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Best, -jay Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: * https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code * https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) * https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) * https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
