API clients prefer oldest available microversions rather than newest

[Andrew Bonney]

As far as I can tell, when Horizon interacts with an OpenStack API via the relevant client (for example Nova client), it currently instantiates the client with a major version integer by default (for example '2') unless a feature requires an explicit microversion (as identified in https://github.com/openstack/horizon/blob/fcf3ae9365ac7f8f95a29dad0c611c7542746a58/openstack_dashboard/api/microversions.py#L29).

If a feature requires a specific microversion range, then the newest microversion from that range will always be used, but for all other requests the oldest available microversion will be used as opposed to the most recent (v2.1 for Nova).

This has the unfortunate side effect of causing the majority of API requests to miss out on potential improvements in the API. For example, as discussed in https://bugs.launchpad.net/nova/+bug/1967314/comments/3, a live migration to a specific host will bypass the Nova scheduler filters and may end up on a host with inappropriate capabilities.

Is the use of the oldest supported API microversions a design decision, or would it be possible to default to the most recent version? If this is a design decision to maintain compatibility, are there any plans to move the minimum version forward (considering for example in Nova where there have been ~90 versions since the default)? Alternatively, would it be preferred for cases such as the one highlighted above to be tackled via additions to MICROVERSION_FEATURES, even though this relates to an improvement rather than a brand new feature?

Tested against Horizon on Xena @ d69b1d414760eba09b19e432d67f82e91620d54

Thanks