fix errors due to new validations

Change-Id: Ibf7f0974a7edb5452fb846391fd47bbcccc93667

doc/source/index.rst

@@ -42,15 +42,6 @@ Implemented
 
    specs/pike/implemented/*
 
-Approved
-^^^^^^^^
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   specs/pike/approved/*
-
 Queens
 ------
 

specs/mitaka/nova-entity-transformer.rst

@@ -63,9 +63,8 @@ implements the three methods:
 * Method that returns key fields and their order.The key fields are mandatory
 * Method that returns a key by given an entity event
 
-*************
 Output Object
-*************
+-------------
 
 The transformer returns an Entity Wrapper, which is a tuple containing an
 entity vertex and a list of (vertex,edge) pairs that describe the entity

specs/mitaka/vitrage-synchronizer.rst

@@ -113,12 +113,12 @@ Collector plugin
 - samples OS services, Nagios, etc.
 - via each OS service REST API
 - method of collection:
-   retrieve OS service elements list. For the purposes of:change
+  retrieve OS service elements list. For the purposes of:change
-   notifications - as part of the periodic collection of the latest snapshot
+  notifications - as part of the periodic collection of the latest snapshot
-    we'd use this method of collection against OS services which doesn't
+  we'd use this method of collection against OS services which doesn't
-    propagates change notification.run on its own collection subprocesses
+  propagates change notification.run on its own collection subprocesses
-    how to discover a change once a snapshot is collected, we'd like to know
+  how to discover a change once a snapshot is collected, we'd like to know
-    which entity was changed from the latest time a snapshot was taken in order
+  which entity was changed from the latest time a snapshot was taken in order
   to enable this, we'd keep a baseline - a data structure which contains for each OS service entity (such as a vm instance), its ID + it latest collection timestamp or a hash which represents its latest state.by comparing the latest snapshot of elements against the baseline, we'd know for which entity we'd like to propagate a notification for.collect deltas for services which reveals this functionality for the purposes of change notifications this is the easy case, where change notifications are simply passed on to whoever registered for them
 - deployment - as a library
 

specs/newton/template-validate-api.rst

@@ -96,7 +96,8 @@ Each result describes the full validation (syntax and content) of one template f
 Response Examples
 ^^^^^^^^^^^^^^^^^
 
-::
+.. code-block:: json
+
     {
       "results": [
         {

specs/ocata/aodh-message-bus-notifications.rst

@@ -22,14 +22,18 @@ Proposed change
 ===============
 
 Aodh `update_method` in vitrage config file will be configured with:
+
 /etc/vitrage/vitrage.conf
-```
+::
+
     [aodh]
     update_method = push
 
 Add a new notification topic in Aodh config file:
+
 /etc/aodh/aodh.conf
-```
+::
+
     [oslo_messaging_notifications]
     topics = vitrage_notifications
 
@@ -77,8 +81,8 @@ performance improvement of getting Aodh alarms
 Other deployer impact
 ---------------------
 
-** Config `update_method` as 'push' in `Aodh` section in vitrage config file.
+ - Config `update_method` as 'push' in `Aodh` section in vitrage config file.
-** Add the `vitrage_notifications` topic in `oslo_messaging_notifications`
+ - Add the `vitrage_notifications` topic in `oslo_messaging_notifications`
    section in Aodh config file.
 
 Developer impact

specs/ocata/multi-tenancy-support.rst

@@ -21,16 +21,15 @@ Proposed change
 ===============
 
 Here is a description, for each of the Vitrage APIs, how it should behave for each tenant:
+
 Get alarms:
- 1.	Find all the alarms with the requested project_id (if the project is admin then show also alarms that has no project_id property)
+ 1. Find all the alarms with the requested project_id (if the project is admin then show also alarms that has no project_id property)
  2. Find all the resources with the requested project_id and return all the alarms that are attached to them.
  3. Merge the results from the previous steps and return it.
 
 Get RCA:
- 1.	Find all the alarms that this alarm has caused, recursively. When reaching an alarm
+ 1.	Find all the alarms that this alarm has caused, recursively. When reaching an alarm that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
-    that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
+ 2. Find all the alarms that caused this alarm, recursively. When reaching an alarm that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
- 2. Find all the alarms that caused this alarm, recursively. When reaching an alarm that
-    is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
  3. Merge the results from the previous steps and return it.
 
 Get Topology:

specs/ocata/static-datasource-configuration.rst

@@ -24,7 +24,7 @@ has a lot of overlapping with the evaluator templates.
 
 In static configuration, there are ``entities`` and their ``relationships``
 
-.. highlight:: yaml
+.. code-block:: yaml
 
   - entities
     - {entity}
@@ -32,7 +32,7 @@ In static configuration, there are ``entities`` and their ``relationships``
 
 In each entity
 
-.. highlight:: yaml
+.. code-block:: yaml
 
   - name:
     id:
@@ -43,7 +43,7 @@ In each entity
 In evaluator templates we define: ``entities``, ``relationship`` and
 ``scenarios``. Each scenario has a condition and actions.
 
-.. highlight:: yaml
+.. code-block:: yaml
 
   - definitions
     - entities
@@ -171,4 +171,4 @@ New format of the template shall be documented.
 References
 ==========
 
-- `http://lists.openstack.org/pipermail/openstack-dev/2016-September/102678.html`_
+None

specs/ocata/vitrage-id.rst

@@ -43,9 +43,9 @@ Datasources:
  - key / value tests : fix field names.
  - Transformers: No change is needed in the Transformers.
  - Processor: Checking if an entity exists in the graph: The entity is currently queried in the
-  Graph according to its Vitrage ID. Instead, it will be queried according to the parameters set.
+   Graph according to its Vitrage ID. Instead, it will be queried according to the parameters set.
-  If the entity exists, it’s original Vitrage ID will be used. Otherwise, a new UUID will be
+   If the entity exists, it’s original Vitrage ID will be used. Otherwise, a new UUID will be
-  generated for vitrage ID via openstack UUIDUtils' generate_uuid.
+   generated for vitrage ID via openstack UUIDUtils' generate_uuid.
 
 
 Update all necessary tests.

specs/pike/implemented/integration-with-mistral.rst

@@ -1,4 +1,5 @@
 ..
+
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.
 

specs/rocky/approved/add-action-list-panel.rst

@@ -192,5 +192,5 @@ adding actions should be documented.
 
 References
 ==========
-.. [#first] https://wiki.openstack.org/wiki/Mistral
+ - https://wiki.openstack.org/wiki/Mistral
-.. [#second] https://docs.openstack.org/rally/latest/
+ - https://docs.openstack.org/rally/latest/