Minor format fixes for Cinder Mitaka specs

Several small RST format fixes, which cause parsing warnings and
errors, and render oddly on specs.openstack.org. Discovered while
working on a spec parsing tool to replace the retired releasestatus
tool.

Change-Id: Ice06999e51f1dd997d370273aae750b3c5ad2ee2

specs/mitaka/add_pagination_to_other_resources.rst

@@ -52,8 +52,9 @@ None
 REST API impact
 ---------------
 
-According the API-wg guideline about pagination, filter and sort[2].
-* GET /v2/{project_id}/{resource}?limit=xxx&marker=xxx&sort=xxx&{filter}=xxx
+According the API-wg guideline about pagination, filter and sort[2]::
+
+  GET /v2/{project_id}/{resource}?limit=xxx&marker=xxx&sort=xxx&{filter}=xxx
   RESP BODY: {"resource_links": [{xxx}],
               "resource": [{xxx}, {xxx}, ..., {xxx}]
              }

specs/mitaka/api-microversions.rst

@@ -118,7 +118,7 @@ A version response would look as follows for GET http://<cinder_URL>:8776
 
 ::
 
-{
+ {
     "versions": [
         {
             "id": "v2.0",
@@ -177,7 +177,7 @@ A version response would look as follows for GET http://<cinder_URL>:8776
             "version": "2.1"
         }
     ]
-}
+ }
 
 This specifies the min and max version that the server can
 understand. min_version will start at 2.0 representing the v2.0 API.
@@ -456,13 +456,13 @@ Primary assignee:
 Work Items
 ----------
 
-Port Manila code for api-microversions
+* Port Manila code for api-microversions
   Status: Done (see https://review.openstack.org/#/c/224910/)
-Add examples of increments and decorators (scottda)
+* Add examples of increments and decorators (scottda)
   Status: Done (see https://github.com/scottdangelo/TestCinderAPImicroversions)
-Implement changes for python-cinderclient (scottda)
-test with python-cinderclient changes (scottda)
-Cinder Doc changes (scottda)
+* Implement changes for python-cinderclient (scottda)
+* test with python-cinderclient changes (scottda)
+* Cinder Doc changes (scottda)
 
 
 Dependencies
@@ -497,4 +497,5 @@ References
 * Manila code for api-microversions: https://review.openstack.org/#/c/207228/8
 * WIP implementation code: https://review.openstack.org/#/c/224910/
 * Test Cases and code: https://github.com/scottdangelo/TestCinderAPImicroversions
+
 ..  _OpenStack API Change Guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html

specs/mitaka/assisted_snapshot_improvements.rst

@@ -43,6 +43,7 @@ API<->Volume service interaction
 
 Establish a snapshot_admin_metadata table which is similar to the
 volume_admin_metadata table::
+
     id : Integer, primary key,
     key : string,
     value : string,
@@ -63,6 +64,7 @@ call for each stage, rather than only a single delete_snapshot call.
 The driver will have a property indicating it supports assisted
 snapshots, which triggers use of the following methods in the manager
 instead of the manager calling the driver's create_snapshot::
+
     create_snapshot_assisted_begin(snapshot_ref)
     create_snapshot_assisted_complete(snapshot_ref)
 

specs/mitaka/backup-snapshots.rst

@@ -47,6 +47,7 @@ Proposed change
 ===============
 
 In summary, the following changes will happen:
+
 * A field "snapshot_id" will be added to the request body of the
   existing backup API.
 * A new column "snapshot_id" will be added to the backups table.
@@ -231,6 +232,7 @@ Documentation Impact
 Documentation will be modified to describe how to use this feature. We
 will make sure both the existing use cases and the new use cases are
 clearly documented to avoid confusion. The following should be covered:
+
 * Do a full backup of a volume with status being 'available' or 'in-use'.
 * Do an incremental backup of a volume with status being 'available' or
   'in-use'.

specs/mitaka/brocade-zone-driver-friendly-zone-names.rst

@@ -66,9 +66,9 @@ is not documenting the ways the volume driver fetch the storage system value.
 It is up to the volume driver to implement a mechanism to retrieve the
 storage system value.
 
-Connection Info samples:
+Connection Info samples::
 
-{
+ {
     'driver_volume_type': 'fibre_channel'
       'data': {
          **'storage_system': 'AMCE_Array',**
@@ -78,9 +78,11 @@ Connection Info samples:
          'target_wwn': '1234567890123',
          'access_mode': 'rw'
       }
-}
-or
-{
+ }
+
+or::
+
+ {
     'driver_volume_type': 'fibre_channel'
       'data': {
          **'storage_system': 'AMCE_Array',**
@@ -90,7 +92,7 @@ or
          'target_wwn': ['1234567890123', '0987654321321'],
          'access_mode': 'rw'
       }
-}
+ }
 
 On attach/detach, Zone Manager will be initialized with **connection_info**
 which is provided by volume driver. Zone Manager in turn will extract the host
@@ -186,11 +188,11 @@ Work Items
 
 - Enhance the zone manager to pass connection_info object to zone driver.
 - Implement Brocade Zone Driver to create zones as per new format
-using the host name and storage system in the connector object.
+  using the host name and storage system in the connector object.
 - Implement Cisco Zone Driver to create zones as per new format using
-the host name and storage system in the connector object.
+  the host name and storage system in the connector object.
 - Volume drivers are expected to add storage system information to
-connector object.
+  connector object.
 - Unit test the zone driver and client code.
 
 

specs/mitaka/brocade-zone-driver-virtualfabrics-support.rst

@@ -73,27 +73,28 @@ service to traverse through the fabrics configured in cinder.conf to identify
 the targets connected to a host and returns a map of initiator and target port
 WWNs for each fabric.
 
-Sample map object returned by the look up service:
+Sample map object returned by the look up service::
 
-            {
-                <Fabric1>: {
-                    'initiator_port_wwn_list':
-                    ('200000051e55a100', '200000051e55a121'..)
-                    'target_port_wwn_list':
-                    ('100000051e55a100', '100000051e55a121'..)
-                }
-                <Virtual_Fabric_2>: {
-                    'initiator_port_wwn_list':
-                    ('300000051e55a100', '300000051e55a121'..)
-                    'target_port_wwn_list':
-                    ('400000051e55a100', '400000051e55a121'..)
-                }
-            }
+  {
+      <Fabric1>: {
+          'initiator_port_wwn_list':
+          ('200000051e55a100', '200000051e55a121'..)
+          'target_port_wwn_list':
+          ('100000051e55a100', '100000051e55a121'..)
+      }
+      <Virtual_Fabric_2>: {
+          'initiator_port_wwn_list':
+          ('300000051e55a100', '300000051e55a121'..)
+          'target_port_wwn_list':
+          ('400000051e55a100', '400000051e55a121'..)
+      }
+  }
 
 The volume driver will process this information to extract initiator and
 target map for each fabric and builds a new initiator_target_map object.
 
-Sample initiator_target_map object:
+Sample initiator_target_map object::
+
         {
             'host WWPN 1': ['target WWPN 1', 'target WWPN 2']
             'host WWPN 2': ['target WWPN 3', 'target WWPN 4']

specs/mitaka/capacity-headroom.rst

@@ -74,12 +74,12 @@ New methods in HostState
 
 * get_capacity()
   - call get_pools()
-  - calculate the capacity info for pool and then sum for each
-    backend
+  - calculate the capacity info for pool and then sum for each backend
 
 Alternatives
 ------------
 Another alternative could be:
+
 * create a new data table which describe capacity info into database
   in scheduler.
 * provide a cinder api to retrieve the capacity info from database.

specs/mitaka/cinder-api-atomic-status-change.rst

@@ -104,7 +104,8 @@ checking the ``status`` of a volume and raise a message if it is not
 then raise a different exception or the same exception with a different
 message.
 
-Skeleton of the procedure:
+Skeleton of the procedure::
+
  result = resource.conditional_update(values, conditions)
  if not result:
      resource = db.get_resource(resource.id)
@@ -124,7 +125,8 @@ call without having changed the DB, which is a problem.  That is why we need a
 loop in the conditional update, to make sure we either succeed on the update or
 we raise the error regardless of racing conditions on the data.
 
-Updated skeleton of the procedure:
+Updated skeleton of the procedure::
+
  while not resource.conditional_update(values, conditions):
      resource = db.get_resource(resource.id)
      raise_right_validation_error(resource)

specs/mitaka/support-volume-glance-metadata-query.rst

@@ -34,7 +34,8 @@ Proposed change
 * Add DB query filter using volume_glance_metadata in api of sqlaclchemy.
 
 * User can use glance metadata to filter volume detail in cinder api.
-  The query url is like this:
+  The query url is like this::
+
       "volumes/detail?glance_metadata={"image_name":"xxx"}"
 
 Alternatives