[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