openstack
/
vitrage-specs
Code Issues Proposed changes

Minor documentation fixes 

Change-Id: Ia3bab4fb6fa4ec687cb044539a0eedd268d1a818
This commit is contained in:
Ifat Afek 2016-12-22 09:16:34 +00:00
parent 5e4a21661a
commit 3d37541db3
9 changed files with 57 additions and 449 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.rst
View File

@ -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

4
doc/source/index.rst
View File

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

29
specs/mitaka/README.rst
View File

@ -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

86
specs/mitaka/entity-graph-consistency-validator.rst
View File

@ -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:
(1) The Vitrage Resource Processor may perform incorrect operations during graph updates, for example due to problems resulting from multi-threading.
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:
(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

87
specs/mitaka/networkx-performance-improvement.rst
View File

@ -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.
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
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.
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

80
specs/mitaka/ui-system-health-visualization.rst
View File

@ -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
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
We will present the system health in sunburest graph with color and labels
that represnt their status
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

98
specs/mitaka/vitrage-resource-processor.rst
View File

@ -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.
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.
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
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.
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.
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

63
specs/mitaka/vitrage-template-validator.rst
View File

@ -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.
If the template is valid, it notify the Evaluator Engine which inserts the template into the template DB. Otherwise, insertion is failed.
Template validator is a part of Vitrage Evaluator. It receives a template,
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

55
specs/newton/template-validate-api.rst
View File

@ -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
============