Compute API version defaults to '2.1' not '2.latest'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-openstackclient |
New
|
Undecided
|
Unassigned |
Bug Description
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-
Setting OS_COMPUTE_
The proposal is to interpret '2' now as novaclient.
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.
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