Add proper microversion support

Registered by Rob Cresswell

Discussion on etherpad:


    - Create per-service dict of feature implementations, with a list of explicit versions that are known to work.
    - Service provides a MAX version (called 'latest') and a MIN version (called 'min_version')
    - When deciding whether to show a feature on the dashboard, check the versions for that feature, in decreasing order, against the version range provided by the API.
    - Use the highest acceptable version, based on the premise that newer should be better (faster, more secure, etc)

... in slightly more detail
    1) Feature dict would look something like:

        "service_1": {
            "feature_foo": [ 3.11, 3.14 ]
        "service_2": {
            "feature_bar": [ 2.3 ]

    2) Retrieve (and cache) the services MIN and MAX versions as a tuple, for example:

        SERVICE_1_MICROVERSIONS = (2.1, 5.2)
        SERVICE_2_MICROVERSIONS = (1.0, 1.9)

    3) Add some magic to allow an easy check for a given feature. This might look something along the lines of:

        is_microversion_feature_available("service", "foo"):

        Behind the scenes, we'll want to find the highest intersection between the list specified by Horizon and the range available in <service>_MICROVERSIONS tuple.

Tricky parts to consider
    - Microversions can break. There are no guarantees that something will be consistently implemented, or implemented at all between API microversions. Because of this, we should be explicit about which microversion to use.
- When adding a new microversion feature, we should have at least two versions; the oldest known working version (this should be in the API docs as the version that introduced the feature) and the current version of the API that this works against. This should allow newer Horizon versions to keep compatibility with older deployments, so there is no reason not to upgrade Horizon.
    - We may end up having to main multiple "feature implementations" per feature, if something was heavily rewritten between microversions. These should probably be listed as separate list items, for example:

        "foo": [ 1.0, 1.1 ]
        "foo_1": [ 1.2 ]

Blueprint information

Richard Jones
Rob Cresswell
Rob Cresswell
Series goal:
Accepted for 12.0.0-pike
Milestone target:
milestone icon pike-1
Started by
Rob Cresswell
Completed by
Rob Cresswell

Related branches



Gerrit topic:,topic:add-cinder-group-types,n,z

Addressed by:
    WIP - Add cinder group types to Admin volume panel

Gerrit topic:,topic:bp/cinder-generic-volume-groups,n,z

Addressed by:
    Add microversion support for consistency groups

Gerrit topic:,topic:bp/microversion-support,n,z

Addressed by:
    Add Microversion support to Horizon


Work Items

This blueprint contains Public information 
Everyone can see this information.