Bug 1312071

Many changes to the Cinder REST API require changes to the consumers of the API.

Each API change bumps a microversion and clients can request a specific
microversion at communication-time, as opposed to what we have now,
where the client uses a specific pinned version that cannot change
(ignore extenions) and core changes cause a major version bump that
everyone has to explicitly switch to.

Basically, it makes client<->server communications more dynamic and less
fragile - with is important for upgrades where some clients are not all the
same version, or for services themselves that communicate with other
services in an expected way.


Use Cases

- Allows developers to modify the Cinder API in backwards compatible way and signal to users of the API dynamically that the change is available without having to create a new API extension.
- Allows developers to modify the Cinder API in a non backwards compatible way whilst still supporting the old behaviour. Users of the REST API are able to decide if they want the Cinder API to behave in the new or old manner on a per request basis. Deployers are able to make new backwards incompatible features available without removing support for prior behaviour as long as there is support to do this by developers.
- Users of the REST API are able to, on a per request basis, decide which version of the API they want to use (assuming the deployer supports the version they want). This means that a deployer who does not upgrade will not break compatibility, and clients that do not upgrade will also remain compatible.

Full spec: https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/api-microversions.html