settingsLogin | Registersettings

[openstack-dev] [nova][python-novaclient] microversion implementation on client side

0 votes

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
  2. move default value of service type to environment variables(default
    value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service type.
Patches are pass all gates, except stable branches and ready for review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 10, 2015 in openstack-dev by Andrey_Kurilin (3,820 points)   2 4

15 Responses

0 votes

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.

  1. 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.

  1. 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:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2015 by Jay_Pipes (59,760 points)   3 11 17
0 votes

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@gmail.com]
Sent: Sunday, April 19, 2015 3:45 AM
To: openstack-dev@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.

  1. 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.

  1. 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:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 20, 2015 by Claudiu_Belu (1,200 points)   3
0 votes

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@gmail.com]
Sent: Sunday, April 19, 2015 3:45 AM
To: openstack-dev@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.

  1. 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.

  1. 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:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 21, 2015 by Hayes,_Graham (1,760 points)   1 3
0 votes

On 04/21/2015 11:35 AM, Hayes, Graham wrote:

From: Jay Pipes [jaypipes@gmail.com]
The existing --os-compute-api-version CLI option should be made to take:

  • 2
  • \d+.\d+
  • "latest"

And nothing else.

Yes - please don't add a flag to the cli (or the python bindings for
that matter)

Isn't a cli flag exactly what Jay was describing?

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.

I haven't had the pleasure(?) of needing to do this, but wouldn't you need to
know what API versions are available before you try to do some task? (In order
to know what actions are available, or what parameters to expect to be returned.)

As I understand it, Jay's proposal is that if you don't specify a version you
get the default (currently version 2, I think), if you do specify a version you
get that version, and if you specify "latest" then you get the most recent
version that the server knows about.

Chris


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 21, 2015 by Chris_Friesen (20,420 points)   4 18 32
0 votes

On Tue, Apr 21, 2015 at 1:27 PM, Chris Friesen chris.friesen@windriver.com
wrote:

On 04/21/2015 11:35 AM, Hayes, Graham wrote:

From: Jay Pipes [jaypipes@gmail.com]

The existing --os-compute-api-version CLI option should be made to take:

  • 2
  • \d+.\d+
  • "latest"

And nothing else.

Yes - please don't add a flag to the cli (or the python bindings for

that matter)

Isn't a cli flag exactly what Jay was describing?

It is, it already exists, it just needs to be made to properly recognize
the required version strings, which is what Jay was suggesting.

This should be done via discovery. If a call requires a micro-version

that is not deployed - return an error.

I haven't had the pleasure(?) of needing to do this, but wouldn't you need
to know what API versions are available before you try to do some task?
(In order to know what actions are available, or what parameters to expect
to be returned.)

When a user needs to know much more about the API than "this is the one
that does Whiz-Bang Feature that I want" then we've failed. Also, many
users aren't probably going to care about API microversions, more likely to
care that GWclient 2.1.2 is the version they need to use Whiz-Bang since
that's what they'll have control over.

As I understand it, Jay's proposal is that if you don't specify a version
you get the default (currently version 2, I think), if you do specify a
version you get that version, and if you specify "latest" then you get the
most recent version that the server knows about.

The way we've been headed in other discovery implementations is to
negotiate the highest compatible version between the client and server
unless a specific version requested. What happens in the client will of
course be client-specific, but as a user I would hope that it either makes
a best effort to fail gracefully or make a lot of noise that includes a
clue as to why it failed.

dt

--

Dean Troyer
dtroyer@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 21, 2015 by Dean_Troyer (13,100 points)   1 3 4
0 votes

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can switch
v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should support
version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client should
discover the nova server supported version. Then cmd choice the latest
version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

The supported version can be discovered by version API (Thanks to Ken'ichi
fix this):
GET '/'
https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with url
'/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported microversion
under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know Andrey
already pay lot of on this. But if we like this way, I also can give some
help on the coding :)

Thanks
Alex

2015-04-10 19:30 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

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
  2. move default value of service type to environment variables(default
    value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service type.
Patches are pass all gates, except stable branches and ready for review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 24, 2015 by Alex_Xu (8,960 points)   1 3 4
0 votes

Thank you for suggestions! I'll try modify patches as soon as possible.

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu soulxu@gmail.com wrote:

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can switch
v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should support
version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client should
discover the nova server supported version. Then cmd choice the latest
version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

The supported version can be discovered by version API (Thanks to Ken'ichi
fix this):
GET '/'

https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with url
'/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported
microversion under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know Andrey
already pay lot of on this. But if we like this way, I also can give some
help on the coding :)

Thanks
Alex

2015-04-10 19:30 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

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
  2. move default value of service type to environment
    variables(default value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service type.
Patches are pass all gates, except stable branches and ready for review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 24, 2015 by Andrey_Kurilin (3,820 points)   2 4
0 votes

2015-04-24 17:24 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

Thank you for suggestions! I'll try modify patches as soon as possible.

np, it's better waiting for more comment before you begin to update the
code first. avoid you need rework again I think :)

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu soulxu@gmail.com wrote:

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can
switch v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should support
version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client
should discover the nova server supported version. Then cmd choice the
latest version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

The supported version can be discovered by version API (Thanks to
Ken'ichi fix this):
GET '/'

https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with url
'/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported
microversion under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know
Andrey already pay lot of on this. But if we like this way, I also can give
some help on the coding :)

Thanks
Alex

2015-04-10 19:30 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

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
  2. move default value of service type to environment
    variables(default value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service type.
Patches are pass all gates, except stable branches and ready for review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 24, 2015 by Alex_Xu (8,960 points)   1 3 4
0 votes

There are no so much messages, since first mail was published 2 weeks ago,
so I don't want spend a lot of time waiting comments, which may not appear.

Btw, some questions appeared in my head related to your suggestions:)

When user execute cmd without --os-compute-version. The nova client should
discover the nova server >supported version. Then cmd choice the latest
version supported both by client and server.

In that case, why X-Compute-API-Version can accept "latest" value? Also,
such discovery will require extra request to API side for every client call.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

From my point of view '--os-compute-version=None' is equal to not specified
value. Maybe, it would be better to accept value "min" for
os-compute-version option.

The supported version can be discovered by version API (Thanks to Ken'ichi
fix this):

Yeah. I saw his patch to novaclient, which adds ability to display
supported microversions - https://review.openstack.org/#/c/173711/

  1. if the microversion non-supported, but user call cmd with
    --os-compute-version, this should return failed.

Imo, it should be implemented on API side(return BadRequest when
X-Compute-API-Version header is presented in V2)

On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu soulxu@gmail.com wrote:

2015-04-24 17:24 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

Thank you for suggestions! I'll try modify patches as soon as possible.

np, it's better waiting for more comment before you begin to update the
code first. avoid you need rework again I think :)

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu soulxu@gmail.com wrote:

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can
switch v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should
support version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client
should discover the nova server supported version. Then cmd choice the
latest version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

The supported version can be discovered by version API (Thanks to
Ken'ichi fix this):
GET '/'

https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with
url '/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported
microversion under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know
Andrey already pay lot of on this. But if we like this way, I also can give
some help on the coding :)

Thanks
Alex

2015-04-10 19:30 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

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
  2. move default value of service type to environment
    variables(default value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service
type. Patches are pass all gates, except stable branches and ready for
review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 24, 2015 by Andrey_Kurilin (3,820 points)   2 4
0 votes

2015-04-24 18:15 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

There are no so much messages, since first mail was published 2 weeks ago,
so I don't want spend a lot of time waiting comments, which may not appear.

Sorry for that, I also replied too late, but let's see what we can help you
more.

Btw, some questions appeared in my head related to your suggestions:)

When user execute cmd without --os-compute-version. The nova client
should discover the nova server >supported version. Then cmd choice the
latest version supported both by client and server.

In that case, why X-Compute-API-Version can accept "latest" value? Also,
such discovery will require extra request to API side for every client call.

I think it is convenient for some case. like give user more easy to try
nova api by some code access the nova api directly. Yes, it need one more
extra request. But if without discover, we can't ensure the client support
server. Maybe client too old for server even didn't support the server's
min version. For better user experience, I think it worth to discover the
version. And we will call keystone each nova client cli call, so it is
acceptable.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

From my point of view '--os-compute-version=None' is equal to not
specified value. Maybe, it would be better to accept value "min" for
os-compute-version option.

I think '--os-compute-version=None' means not specified version request
header when send api request to server. The server behavior is if there
isn't value specified, the min version will be used.

The supported version can be discovered by version API (Thanks to
Ken'ichi fix this):

Yeah. I saw his patch to novaclient, which adds ability to display
supported microversions - https://review.openstack.org/#/c/173711/

Yea

  1. if the microversion non-supported, but user call cmd with
    --os-compute-version, this should return failed.

Imo, it should be implemented on API side(return BadRequest when
X-Compute-API-Version header is presented in V2)

Emm.... I'm not sure. Because GET '/v2/' already can be used to discover
microversion support or not. Sounds like add another way to support
discover? And v2 api didn't return fault with some extra header, that
sounds like behavior and back-incompatible change.

On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu soulxu@gmail.com wrote:

2015-04-24 17:24 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

Thank you for suggestions! I'll try modify patches as soon as possible.

np, it's better waiting for more comment before you begin to update the
code first. avoid you need rework again I think :)

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu soulxu@gmail.com wrote:

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can
switch v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should
support version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client
should discover the nova server supported version. Then cmd choice the
latest version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return
the min version of server supported.

The supported version can be discovered by version API (Thanks to
Ken'ichi fix this):
GET '/'

https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with
url '/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported
microversion under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know
Andrey already pay lot of on this. But if we like this way, I also can give
some help on the coding :)

Thanks
Alex

2015-04-10 19:30 GMT+08:00 Andrey Kurilin akurilin@mirantis.com:

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
  2. move default value of service type to environment
    variables(default value is hardcoded in novaclient code now)
  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

Current implementation uses "compute" as default value for service
type. Patches are pass all gates, except stable branches and ready for
review:

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 24, 2015 by Alex_Xu (8,960 points)   1 3 4
...