Open Stack

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 [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.
> 
> 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-request at 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-request at 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 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.