[openstack-dev] [nova][python-novaclient] microversion implementation on client side
    Jay Pipes 
    jaypipes at gmail.com
       
    Sun Apr 19 00:45:29 UTC 2015
    
    
  
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
>
    
    
More information about the OpenStack-dev
mailing list