Open Stack

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