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 [[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 >
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 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
