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 [[email protected]] Sent: Sunday, April 19, 2015 3:45 AM To: [email protected] 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
