Add proper microversion support

Registered by Rob Cresswell on 2016-12-05

Discussion on etherpad:

https://etherpad.openstack.org/p/horizon-microversion-support

THE PLAN:

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

    MICROVERSION_FEATURES = {
        "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"):
            <horizon_feature_implementation>

        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.
Reference: http://docs.openstack.org/developer/nova/api_microversion_dev.html#removing-an-api-method
- 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

Status:
Complete
Approver:
Richard Jones
Priority:
High
Drafter:
Rob Cresswell
Direction:
Approved
Assignee:
Rob Cresswell
Definition:
Approved
Series goal:
Accepted for 12.0.0-pike
Implementation:
Implemented
Milestone target:
milestone icon pike-1
Started by
Rob Cresswell on 2016-12-14
Completed by
Rob Cresswell on 2017-04-03

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:add-cinder-group-types,n,z

Addressed by: https://review.openstack.org/410490
    WIP - Add cinder group types to Admin volume panel

Gerrit topic: https://review.openstack.org/#q,topic:bp/cinder-generic-volume-groups,n,z

Addressed by: https://review.openstack.org/410860
    Add microversion support for consistency groups

Gerrit topic: https://review.openstack.org/#q,topic:bp/microversion-support,n,z

Addressed by: https://review.openstack.org/411919
    Add Microversion support to Horizon

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.