Fix comments in microversion doc
This fix some comments left in
I68e6d2a4a681e6588e43e02378a111fd00391f08 for microversion doc.
Change-Id: I29ab6f625df59ba3732f9730a610e14dfe6094ea
diff --git a/doc/source/microversion_testing.rst b/doc/source/microversion_testing.rst
index bb48b3f..0b72809 100644
--- a/doc/source/microversion_testing.rst
+++ b/doc/source/microversion_testing.rst
@@ -2,9 +2,9 @@
How To Implement Microversion Tests
===================================
-Tempest provides stable interfaces to test API microversion.
+Tempest provides stable interfaces to test API Microversion.
For Details, see: `API Microversion testing Framework`_
-This document explains how to implement microversion tests using those
+This document explains how to implement Microversion tests using those
interfaces.
.. _API Microversion testing Framework: http://docs.openstack.org/developer/tempest/library/api_microversion_testing.html
@@ -15,12 +15,14 @@
* Add configuration options for specifying test target Microversions.
We need to specify test target Microversions because the supported
- microversions may be different between OpenStack clouds. For operating
+ Microversions may be different between OpenStack clouds. For operating
multiple Microversion tests in a single Tempest operation, configuration
options should represent the range of test target Microversions.
New configuration options are:
- - min_microversion
- - max_microversion
+
+ * min_microversion
+ * max_microversion
+
Those should be defined under respective section of each service.
For Example::
[compute]
@@ -31,7 +33,7 @@
How To Implement Microversion Tests
"""""""""""""""""""""""""""""""""""
-Step1: Add skip logic based on configured microversion range
+Step1: Add skip logic based on configured Microversion range
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Add logic to skip the tests based on Tests class and configured Microversion
@@ -61,7 +63,7 @@
Select appropriate Microversion which needs to be used
to send with API request.
api_version_utils.select_request_microversion function can be used
-to select the appropriate microversion which will be used for API request.
+to select the appropriate Microversion which will be used for API request.
For example::
@classmethod
@@ -77,11 +79,11 @@
''''''''''''''''''''''''''''''''''''''''''
Microversion selected by Test Class in previous step needs to be set on
-service clients so that APIs can be requested with selected microversion.
+service clients so that APIs can be requested with selected Microversion.
Microversion can be defined as global variable on service clients which
can be set using fixture.
-Also microversion header name needs to be defined on service clients which
+Also Microversion header name needs to be defined on service clients which
should be constant because it is not supposed to be changed by project
as per API contract.
For example::
@@ -91,16 +93,16 @@
class BaseClient1(rest_client.RestClient):
api_microversion_header_name = 'X-OpenStack-Nova-API-Version'
-Now test class can set the selected microversion on required service clients
-using fixture which can take care of reseting the same once tests is completed.
+Now test class can set the selected Microversion on required service clients
+using fixture which can take care of resetting the same once tests is completed.
For example::
def setUp(self):
- super(BaseTestCase1,, self).setUp()
+ super(BaseTestCase1, self).setUp()
self.useFixture(api_microversion_fixture.APIMicroversionFixture(
self.request_microversion))
-Service clients needs to add set microversion in API request header which
+Service clients needs to add set Microversion in API request header which
can be done by overriding the get_headers() method of rest_client.
For example::
@@ -119,20 +121,20 @@
Step4: Separate Test classes for each Microversion
''''''''''''''''''''''''''''''''''''''''''''''''''
-This is last step to implement microversion test class.
+This is last step to implement Microversion test class.
-For any microversion tests, basically we need to implement a
+For any Microversion tests, basically we need to implement a
separate test class. In addition, each test class defines its
-microversion range with class variable like min_microversion
+Microversion range with class variable like min_microversion
and max_microversion. Tests will be valid for that defined range.
-If that range is out of configured microversion range then, test
+If that range is out of configured Microversion range then, test
will be skipped.
*NOTE: Microversion testing is supported at test class level not at individual
test case level.*
For example:
-Below test is applicable for microversion from 2.2 till 2.9::
+Below test is applicable for Microversion from 2.2 till 2.9::
class BaseTestCase1(api_version_utils.BaseMicroversionTest,
tempest.test.BaseTestCase):
@@ -146,7 +148,7 @@
[..]
-Below test is applicable for microversion from 2.10 till latest::
+Below test is applicable for Microversion from 2.10 till latest::
class Test2(BaseTestCase1):
min_microversion = '2.10'
@@ -160,25 +162,25 @@
Notes about Compute Microversion Tests
"""""""""""""""""""""""""""""""""""
Some of the compute Microversion tests have been already implemented
-with the microversion testing framework. So for further tests only
+with the Microversion testing framework. So for further tests only
step 4 is needed.
Along with that JSON response schema might need versioning if needed.
Compute service clients strictly validate the response against defined JSON
schema and does not allow additional elements in response.
-So if that microversion changed the API response then schema needs to be version.
+So if that Microversion changed the API response then schema needs to be version.
New JSON schema file needs be defined with new response attributes and service
client methods will select the schema based on requested microversion.
-If microversion tests are implemented randomly means not
-in sequence order(v2.20 tests added and previous microversion tests are not yet added)
-then, still schema might needs to be version for older microversion if they changed
+If Microversion tests are implemented randomly means not
+in sequence order(v2.20 tests added and previous Microversion tests are not yet added)
+then, still schema might needs to be version for older Microversion if they changed
the response.
-This is because Nova microversion includes all the previous microversions behvaior.
+This is because Nova Microversion includes all the previous Microversions behavior.
For Example:
- Implementing the v2.20 microversion tests before v2.9 and 2.19-
+ Implementing the v2.20 Microversion tests before v2.9 and 2.19-
v2.20 API request will respond as latest behavior of Nova till v2.20,
and in v2.9 and 2.19, server response has been changed so response schema needs
to be version accordingly.
@@ -203,4 +205,4 @@
* `2.2`_
- .. _2.2: http://docs.openstack.org/developer/nova/api_microversion_history.html#id2
+ .. _2.2: http://docs.openstack.org/developer/nova/api_microversion_history.html#id2