womax/nova
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge "doc: completes microversion use-cases in api concept doc"

Browse Source
This commit is contained in:
Jenkins
2016-01-25 02:35:24 +00:00
committed by Gerrit Code Review
parent a162c766fc 670ae42359
commit 1b3fa9d316
1 changed files with 28 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
api-guide/source/microversions.rst
+28 -17
View File
@@ -15,24 +15,35 @@
Microversions Microversions
============= =============
API v2.1 supports Microversions: small, documented changes to the API. A user API v2.1 supports microversions: small, documented changes to the API. A user
can use Microversions to discover the latest API version supported in their can use microversions to discover the latest API microversion supported in
cloud. A cloud that is upgraded to support newer versions will still support their cloud. A cloud that is upgraded to support newer microversions will still
all older versions to maintain the backward compatibility for those users who support all older microversions to maintain the backward compatibility for
depend on older versions. Users can also discover new features easily with those users who depend on older microversions. Users can also discover new
Microversions, so that they can benefit from all the advantages and features easily with microversions, so that they can benefit from all the
improvements of the current cloud. advantages and improvements of the current cloud.
There are multiple cases which you can resolve with Microversions: There are multiple cases which you can resolve with microversions:
Legacy v2 API user with new cloud Older clients with new cloud
================================= ============================
The minimum version of Microversions is `2.1`, which is a version compatible Before using an old client to talk to a newer cloud, the old client can check
with the legacy v2 API. The legacy v2 API user doesn't need to worry that their the minimum version of microversions to verify whether the cloud is compatible
older client software will be broken when their cloud is upgraded with new with the old API. This prevents the old client from breaking with backwards
versions. And the cloud operator doesn't need to worry that upgrading their incompatible API changes.
cloud to newer versions will break any user with older clients that don't
expect these changes.
TODO: add more use-cases for Microversions Currently the minimum version of microversions is `2.1`, which is a
microversion compatible with the legacy v2 API. That means the legacy v2 API
user doesn't need to worry that their older client software will be broken when
their cloud is upgraded with new versions. And the cloud operator doesn't need
to worry that upgrading their cloud to newer versions will break any user with
older clients that don't expect these changes.
User discovery of available features between clouds
===================================================
The new features can be discovered by microversions. The user client should
check the microversions firstly, and new features are only enabled when clouds
support. In this way, the user client can work with clouds that have deployed
different microversions simultaneously.