[openstack-dev] [nova][python-novaclient] microversion implementation on client side
graham.hayes at hp.com
Tue Apr 21 17:35:24 UTC 2015
On 04/20/2015 06:30 PM, Claudiu Belu wrote:
> 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,
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Sunday, April 19, 2015 3:45 AM
> To: openstack-dev at 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.
>> 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
> -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.
>> 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
>> Best regards,
>> Andrey Kurilin.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Yes - please don't add a flag to the cli (or the python bindings for
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
This should be done via discovery. If a call requires a micro-version
that is not deployed - return an error.
More information about the OpenStack-dev