Compute API version defaults to '2.1' not '2.latest'

[Dean Troyer]

We attempted to set the default Compute API to 2.latest but that change did not work. OSC's default Compute API is set to '2.1' intentionally to maintain backward-compatibility. This strategy will have to change if/when the minimum Compute API version is ever raised. But we are also missing out on some things, so how can we do this?

Setting OS_COMPUTE_API_VERSION=2 has always been valid, and in fact is the default in clouds.yaml (os-client-config) when OSC does not override it. This is usually interpreted to mean '2.0', which is no longer a valid version, and in fact was never accepted by OSC (only '2' was valid before microversions were introduced).

The proposal is to interpret '2' now as novaclient.API_MAX_VERSION (At this writing it is 2.41). This would cause changes in behavior for anyone explicitly setting OS_COMPUTE_API_VERSION=2.

One question is should this change wait for OSC 4.0 as it does change behaviour? I think it should, but want to get some feedback from users.

[Rui Chen (kiwik-chenrui)]

In most use cases it should be ok when we interpret '2' as novaclient.API_MAX_VERSION, because novaclient api microversion match with nova service microversion.

But if we use high version client(Pike) to talk with low version service(Mitaka), it might not work, when novaclient.API_MAX_VERSION is out of the range that nova service supported, and nova service return HTTP406 to refuse the request. So I think we should do api version discovery and take min(client.microversion, service.microversion) to init novaclient.

I prefer to wait for osc 4.0 to land the change, we don't know exactly which commands will break[1]. I have an idea, we should to add non-voting jenkins job to run functional tests with --os-compute-api-version 2.latest, help us to find the gap.

[1]: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/console.py#L134-L138