Minor documentation fixes

Change-Id: Ia3bab4fb6fa4ec687cb044539a0eedd268d1a818

README.rst

@@ -7,9 +7,9 @@ Team and repository tags
 
 .. Change things from this point on
 
-===============================
+================================
 OpenStack Vitrage Specifications
-===============================
+================================
 
 This git repository is used to hold approved design specifications for additions
 to the Vitrage project. Reviews of the specs are done in gerrit, using a similar

doc/source/index.rst

@@ -21,8 +21,8 @@ Newton
 
    specs/newton/*
 
-Newton
+Ocata
-------
+-----
 
 .. toctree::
    :glob:

specs/mitaka/README.rst

@@ -1,29 +0,0 @@
-Mitaka specifications
-=====================
-
-This directory is supposed to hold approved specifications for the 'Mitaka' release.
-You are welcome in contributing to Vitrage!
-
-
-Vitrage
--------
-
-Vitrage Project introduces a Root Cause Analysis (RCA) engine for organizing,
-analyzing and expanding OpenStack alarms & events, yielding insights
-regarding the Root Cause of problems and deducing the existence of problems
-before they are directly detected.
-
-Vitrage Project Resources
--------------------------
-
-* Project status, bugs, and blueprints are tracked on
-  `Launchpad <https://launchpad.net/vitrage>`_
-
-* Additional resources are linked from the project
-  `Wiki <https://wiki.openstack.org/wiki/Vitrage>`_ page
-
-
-License
--------
-
-Apache License Version 2.0 http://www.apache.org/licenses/LICENSE-2.0

specs/mitaka/entity-graph-consistency-validator.rst

@@ -4,72 +4,43 @@
 
  http://creativecommons.org/licenses/by/3.0/legalcode
 
-==========================
+==========================================
-Vitrage Resource Processor
+Vitrage Entity Graph Consistency Validator
-==========================
+==========================================
 
 https://blueprints.launchpad.net/vitrage/+spec/entity-graph-consistency-validator
 
-The Entity Graph may have mistakes, such as an incorrect resource state, and we would like to detect and repair such errors.
+The Entity Graph may have mistakes, such as an incorrect resource state, and
+we would like to detect and repair such errors.
 
 Problem description
 ===================
 
-The Entity Graph is a living graph which is updated all the time with the data received from the synchronizer(s). The Entity Graph may have errors and become inconsistent compared to the state of the Cloud, which may occur due to:
+The Entity Graph is a living graph which is updated all the time with the data
-(1)	The Vitrage Resource Processor may perform incorrect operations during graph updates, for example due to problems resulting from multi-threading.
+received from the synchronizer(s). The Entity Graph may have errors and become
+inconsistent compared to the state of the Cloud, which may occur due to:
+(1)	The Vitrage Resource Processor may perform incorrect operations during
+graph updates, for example due to problems resulting from multi-threading.
 (2)	Missing updates from the synchronizer(s).
 
 Proposed change
 ===============
 
-We would like to check the Entity Graph each set interval (configurable) and validate the consistency of its resources and state. If the Entity Graph is incorrect, it will repair it. When needed, it might consult the synchronizer(s) to retrieve missing data.
+We would like to check the Entity Graph each set interval (configurable) and
+validate the consistency of its resources and state. If the Entity Graph is
+incorrect, it will repair it. When needed, it might consult the synchronizer(s)
+to retrieve missing data.
 
 Alternatives
 ------------
 
 None
 
-Data model impact
------------------
-
-None
-
 REST API impact
 ---------------
 
 None
 
-Security impact
----------------
-
-None
-
-Pipeline impact
----------------
-
-None
-
-Other end user impact
----------------------
-
-None
-
-Performance/Scalability Impacts
--------------------------------
-
-None
-
-
-Other deployer impact
----------------------
-
-None
-
-Developer impact
-----------------
-
-None
-
 
 Implementation
 ==============
@@ -80,32 +51,3 @@ Assignee(s)
 Primary assignee:
 	alexey_weyl <alexey.weyl@alcatel-lucent.com>
 
-Work Items
-----------
-
-None
-
-Future lifecycle
-================
-
-None
-
-Dependencies
-============
-
-None
-
-Testing
-=======
-
-None
-
-Documentation Impact
-====================
-
-None
-
-References
-==========
-
-None

specs/mitaka/networkx-performance-improvement.rst

@@ -10,63 +10,23 @@ NetworkX Performance Improvement
 
 https://blueprints.launchpad.net/vitrage/+spec/networkx-performance-improvement
 
-Many CRUD operations can be performed on the Entity Graph simultaneously. This can cause inconsistency regarding the resources and states on the graph.
+Many CRUD operations can be performed on the Entity Graph simultaneously.
+This can cause inconsistency regarding the resources and states on the graph.
 
 Problem description
 ===================
 
-Many CRUD operations can be performed on the Entity Graph simultaneously. This can cause inconsistency regarding the resources and states on the graph.
+Many CRUD operations can be performed on the Entity Graph simultaneously.
+This can cause inconsistency regarding the resources and states on the graph.
 
 Proposed change
 ===============
 
-We would like to have graph versioning, which will held two copies of the Entity Graph: (1) Stable copy of the last consistent graph, and (2) Dynamic copy of the graph which is updated by the Vitrage Resource Processor. Every set interval the changes inserted to the dynamic graph will be updated to the stable graph, resulting in the stable graph being up to date.
+We would like to have graph versioning, which will held two copies of the
-
+Entity Graph: (1) Stable copy of the last consistent graph, and (2) Dynamic
-Alternatives
+copy of the graph which is updated by the Vitrage Resource Processor.
-------------
+Every set interval the changes inserted to the dynamic graph will be updated
-
+to the stable graph, resulting in the stable graph being up to date.
-None
-
-Data model impact
------------------
-
-None
-
-REST API impact
----------------
-
-None
-
-Security impact
----------------
-
-None
-
-Pipeline impact
----------------
-
-None
-
-Other end user impact
----------------------
-
-None
-
-Performance/Scalability Impacts
--------------------------------
-
-None
-
-
-Other deployer impact
----------------------
-
-None
-
-Developer impact
-----------------
-
-None
 
 
 Implementation
@@ -78,32 +38,3 @@ Assignee(s)
 Primary assignee:
 	alexey_weyl <alexey.weyl@alcatel-lucent.com>
 
-Work Items
-----------
-
-None
-
-Future lifecycle
-================
-
-None
-
-Dependencies
-============
-
-None
-
-Testing
-=======
-
-None
-
-Documentation Impact
-====================
-
-None
-
-References
-==========
-
-None

specs/mitaka/ui-system-health-visualization.rst

@@ -20,54 +20,8 @@ Missing visualization of the system status.
 Proposed change
 ===============
 
-We will present the system health in sunburest graph with color and labels that represnt their status
+We will present the system health in sunburest graph with color and labels
-
+that represnt their status
-Alternatives
-------------
-
-None
-
-Data model impact
------------------
-
-None
-
-REST API impact
----------------
-
-None
-
-Security impact
----------------
-
-None
-
-Pipeline impact
----------------
-
-None
-
-Other end user impact
----------------------
-
-None
-
-Performance/Scalability Impacts
--------------------------------
-
-None
-
-
-Other deployer impact
----------------------
-
-None
-
-Developer impact
-----------------
-
-None
-
 
 Implementation
 ==============
@@ -77,33 +31,3 @@ Assignee(s)
 
 Primary assignee:
 	alon-heller <alon.heller@alcatel-lucent.com>
-
-Work Items
-----------
-
-None
-
-Future lifecycle
-================
-
-None
-
-Dependencies
-============
-
-None
-
-Testing
-=======
-
-None
-
-Documentation Impact
-====================
-
-None
-
-References
-==========
-
-None

specs/mitaka/vitrage-resource-processor.rst

@@ -10,66 +10,32 @@ Vitrage Resource Processor
 
 https://blueprints.launchpad.net/vitrage/+spec/vitrage-resource-processor
 
-When Vitrage initializes we need to create the Entity Graph on which the Vitrage will run it’s algorithms (sub graph matching, BFS, DFS etc.) and perform the actions (RCA, deduced alarms etc.). After the initialization of the graph, the resources changes are being processed and pushed to the Entity Graph.
+When Vitrage initializes we need to create the Entity Graph on which the
+Vitrage will run it’s algorithms (sub graph matching, BFS, DFS etc.) and
+perform the actions (RCA, deduced alarms etc.). After the initialization
+of the graph, the resources changes are being processed and pushed to the
+Entity Graph.
 
 Problem description
 ===================
 
-Vitrage does not have a full Entity Graph of the resources and their state when it initializes.
+Vitrage does not have a full Entity Graph of the resources and their state
+when it initializes.
 Vitrage needs to be consistent with the updated and new resources.
 
 Proposed change
 ===============
 
-When Vitrage initializes we need to build the up to date entity graph, so we can run the different algorithms on it and perform the required actions. To perform we require the full resources list from the synchronizer.
+When Vitrage initializes we need to build the up to date entity graph, so we
-In order for the Entity Graph to be constructed, it will need updates on changes in the cloud (e.g., machine creation/termination), and guidance on how resources should be linked to each other (e.g., a virtual machine resides on a physical host, which in turn belongs to an availability zone, etc.). For this purpose, each synchronizer will also update a configuration file - the entity graph template - which specifies for each resource what and how to locate the specific resources to link to.
+can run the different algorithms on it and perform the required actions.
-
+To perform we require the full resources list from the synchronizer.
-Alternatives
+In order for the Entity Graph to be constructed, it will need updates on
-------------
+changes in the cloud (e.g., machine creation/termination), and guidance on how
-
+resources should be linked to each other (e.g., a virtual machine resides on
-None
+a physical host, which in turn belongs to an availability zone, etc.).
-
+For this purpose, each synchronizer will also update a configuration file -
-Data model impact
+the entity graph template - which specifies for each resource what and how to
------------------
+locate the specific resources to link to.
-
-None
-
-REST API impact
----------------
-
-None
-
-Security impact
----------------
-
-None
-
-Pipeline impact
----------------
-
-None
-
-Other end user impact
----------------------
-
-None
-
-Performance/Scalability Impacts
--------------------------------
-
-None
-
-
-Other deployer impact
----------------------
-
-None
-
-Developer impact
-----------------
-
-None
-
 
 Implementation
 ==============
@@ -80,33 +46,3 @@ Assignee(s)
 Primary assignee:
 	alexey_weyl <alexey.weyl@alcatel-lucent.com>
 	dan-ofek <dan.ofek@alcatel-lucent.com>
-
-Work Items
-----------
-
-None
-
-Future lifecycle
-================
-
-None
-
-Dependencies
-============
-
-None
-
-Testing
-=======
-
-None
-
-Documentation Impact
-====================
-
-None
-
-References
-==========
-
-None

specs/mitaka/vitrage-template-validator.rst

@@ -12,21 +12,26 @@ Launchpad blueprint:
 
 https://blueprints.launchpad.net/vitrage/+spec/template-validator
 
-Vitrage Evaluator serves as workflow manager controlling the analysis and activation of templates and execution of template actions.
+Vitrage Evaluator serves as workflow manager controlling the analysis and
+activation of templates and execution of template actions.
 
-Template Validator ensures that a new template is correct. Meaning, it conforms with Vitrage Template Standard.
+Template Validator ensures that a new template is correct. Meaning, it conforms
+with Vitrage Template Standard.
 
 
 Problem description
 ===================
 
-Templates do not always meet the Vitrage Template Standard. For example, unsupported action, invalid alarm name, incorrect graph template and etc.
+Templates do not always meet the Vitrage Template Standard. For example,
+unsupported action, invalid alarm name, incorrect graph template and etc.
 
 Proposed change
 ===============
 
-Template validator is a part of Vitrage Evaluator. It receives a template, runs over it and checks its correctness.
+Template validator is a part of Vitrage Evaluator. It receives a template,
-If the template is valid, it notify the Evaluator Engine which inserts the template into the template DB. Otherwise, insertion is failed.
+runs over it and checks its correctness.
+If the template is valid, it notify the Evaluator Engine which inserts the
+template into the template DB. Otherwise, insertion is failed.
 
 Alternatives
 ------------
@@ -39,51 +44,3 @@ None
 REST API impact
 ---------------
 The validator runs when a new template is added through API create call.
-
-Versioning impact
------------------
-None
-
-Other end user impact
----------------------
-None
-
-Deployer impact
----------------
-None
-
-Developer impact
-----------------
-None
-
-Horizon impact
---------------
-None
-
-Implementation
-==============
-
-Assignee(s)
------------
-TBD
-
-Work Items
-----------
-None
-
-Dependencies
-============
-None
-
-Testing
-=======
-TBD
-
-Documentation Impact
-====================
-TBD
-
-
-References
-==========
-TBD

specs/newton/template-validate-api.rst

@@ -33,16 +33,6 @@ The template validate API returns a result that contains the following fields:
 #. message - error message
 #. status code
 
-Alternatives
-------------
-
-None
-
-Data model impact
------------------
-
-None
-
 REST API impact
 ---------------
 
@@ -52,7 +42,7 @@ Template Validate
 Validate Vitrage template(s)
 
 POST /
-~~~~~
+~~~~~~
 
 Headers
 ^^^^^^^
@@ -126,38 +116,6 @@ Response Examples
       ]
     }
 
-Security impact
----------------
-
-None
-
-Pipeline impact
----------------
-
-None
-
-Other end user impact
----------------------
-
-None
-
-Performance/Scalability Impacts
--------------------------------
-
-None
-
-
-Other deployer impact
----------------------
-
-None
-
-Developer impact
-----------------
-
-None
-
-
 Implementation
 ==============
 
@@ -166,17 +124,6 @@ Assignee(s)
 
 liat har-tal <liat.har-tal@nokia.com>
 
-
-Work Items
-----------
-
-None
-
-Future lifecycle
-================
-
-None
-
 Dependencies
 ============