nova entity transformer bp
Change-Id: Ic32f4c94b77fdfb3d126fd2aa437687435faead0
This commit is contained in:
Liat Har-Tal
parent
934688090c
commit
1057c448fb
199
specs/mitaka/nova-entity-transformer.rst
Normal file
199
specs/mitaka/nova-entity-transformer.rst
Normal file
@ -0,0 +1,199 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=======================
|
||||
Nova Entity Transformer
|
||||
=======================
|
||||
|
||||
https://blueprints.launchpad.net/vitrage/+spec/nova-entity-transformer
|
||||
|
||||
When an entity event is being introduced into Vitrage graph, it must
|
||||
be transformed into a type which can be handled by the graph.
|
||||
The Entity transformer is responsible for converting an entity event
|
||||
into entity wrapper. Each entity type has his own transformer.
|
||||
|
||||
All transformers should be written in python and added to vitrage.conf.
|
||||
The Entity Transformer Engine allows a service provider to extend
|
||||
support for other entities by writing a designated transformer for each
|
||||
entity type.
|
||||
|
||||
The first transformers to implement are:
|
||||
|
||||
* Nova Instance transformer
|
||||
* Nova Host transformer
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
In Vitrage graph, each (instance of an) entity is represented as a vertex.
|
||||
Therefore, the output of a transformer is a vertex for the given entity
|
||||
(an "entity vertex").
|
||||
In addition, the transformer also returns a list of (vertex, edge)-pairs.
|
||||
The vertex in each pair describes a neighbor with limited properties, and the
|
||||
edge represents the connection between both vertices, describing their
|
||||
relationship.
|
||||
|
||||
There are different Entity Types that should be supported by Vitrage:
|
||||
|
||||
* Openstack types (Nova.instance, Nova.host and etc.)
|
||||
* Non-Openstack types (Nagios tests, Physical resources and etc.)
|
||||
|
||||
Note: in Vitrage Graph, each vertex contains a dictionary of key-value pairs
|
||||
which represents the entity properties. Similarly, each edge contains a
|
||||
dictionary of key-value pairs which represents aspects of the relation between
|
||||
two vertices.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
When the Entity Processor receives a new entity event, it asks the Entity
|
||||
Transformer to convert the event into an object which the processor can then
|
||||
enter into the Vitrage Graph.
|
||||
|
||||
Transformer Operation: When receiving an entity event, the Transformer Engine
|
||||
first recognizes the entity type and accordingly activates the corresponding
|
||||
transformer. Each transformer inherits from the Transformer base class and
|
||||
implements the three methods:
|
||||
|
||||
* Method that returns an entity wrapper
|
||||
* 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
|
||||
neighbors (relationships).
|
||||
|
||||
**Entity (source) vertex description:**
|
||||
|
||||
Mandatory properties:
|
||||
|
||||
* ``key`` - For Openstack entities this is the Openstack ID. For non-Openstack
|
||||
entities this is an ID which will generated by Vitrage
|
||||
* ``Type`` - Resource \ Physical Resource \ Alarm \ Tests Results
|
||||
* ``Sub Type`` - Alarm Name, host, instance, switch and etc.
|
||||
* ``Entity Name``
|
||||
* ``Is Deleted``- needed for graph maintenance and marks items that can be
|
||||
gathered by the garbage collector
|
||||
|
||||
Optional properties (vertex metadata)
|
||||
|
||||
* ``State``
|
||||
* ``Project ID``
|
||||
|
||||
The optional properties list is flexible and can be changed as needed.
|
||||
In addition, each entity type can have its own relevant properties.
|
||||
|
||||
**(vertex, edge) Pairs:**
|
||||
|
||||
The pair describes a entity’s neighbor vertex and their relationship.
|
||||
Relationships can be both physical, virtual or (in the future) logical
|
||||
|
||||
``Target vertex description``:
|
||||
|
||||
The vertex in the pair must have sufficient data to help specify uniquely
|
||||
which vertex in the Vitrage Graph will be connected to this entity.
|
||||
Currently, the minimal information needed for this is:
|
||||
|
||||
* ID - For each entity, must have the data which vertex it connects
|
||||
* Type - Resource \ Physical Resource \ Alarm \ Tests Results
|
||||
* Sub Type - Alarm Name, host, instance, switch and etc.
|
||||
|
||||
``Edge description``:
|
||||
|
||||
* Source ID Entity ID
|
||||
* Target ID - For each entity, must have the data which vertex it connects
|
||||
* Relation Type - contains, run, attached and etc.
|
||||
|
||||
**Event Type:**
|
||||
|
||||
The type of the event as it happened. Possible options:
|
||||
|
||||
* CREATE - New entity is created
|
||||
* UPDATE - The entity has been updated
|
||||
* DELETE - When the entity is deleted
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
TBD
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Versioning impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Deployer impact
|
||||
---------------
|
||||
|
||||
TBD
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
TBD
|
||||
|
||||
Horizon impact
|
||||
--------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
liat har-tal
|
||||
|
||||
|
||||
Work Items
|
||||
----------
|
||||
None
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
All code will be tested
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
None
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Vitrage project <https://wiki.openstack.org/wiki/Vitrage>
|
||||
127
specs/mitaka/vitrage-evaluator-engine.rst
Normal file
127
specs/mitaka/vitrage-evaluator-engine.rst
Normal file
@ -0,0 +1,127 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
================
|
||||
Evaluator Engine
|
||||
================
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/vitrage/+spec/evalutor-engine
|
||||
|
||||
Vitrage Evaluator serves as workflow manager controlling the analysis and activation of templates and execution of template actions.
|
||||
|
||||
Evaluator engine is the main core of Vitrage evaluator which responsible for managing the templates, executing them over Vitrage Graph and running their action.
|
||||
|
||||
::
|
||||
|
||||
+---------------------+
|
||||
| |
|
||||
| <------------------+
|
||||
| Vitrage Graph | |
|
||||
| | +-------+-------------------+
|
||||
| | | Vitrage Evaluator |
|
||||
+--------------+------+ | |
|
||||
| | +------+ |
|
||||
| | | RCA | |
|
||||
+-----------------> | | |
|
||||
| +------+ |
|
||||
| +------+ |
|
||||
+---------------------+ | |Deduce| |
|
||||
| <----------+ |Alarm | |
|
||||
| Vitrage Notifier | | +------+ |
|
||||
| | | |
|
||||
| | +---------------------------+
|
||||
| |
|
||||
+---------------------+
|
||||
|
||||
|
||||
Problem description
|
||||
====================
|
||||
|
||||
Vitrage requires a component that is responsible for managing and executing templates, which are the basis for the different algorithms used in Vitrage, such as RCA.
|
||||
|
||||
**Use cases:**
|
||||
#. When a new **instance** is added/removed/updated in the Vitrage Graph, find the templates relevant to this change and compare the pattern specified in each template to the new graph structure. For each pattern match found, execute the actions specified in the template.
|
||||
|
||||
#. When a new **alarm** is added/removed/updated in the Vitrage Graph, find the templates relevant to this change and compare the pattern specified in each template to the new graph structure. For each pattern match found, execute the actions specified in the template.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
**Managing Templates**
|
||||
|
||||
Users can perform CRUD actions on templates, in order to make changes to the use cases Vitrage supports. Specifically, when adding a template it should be added and stored in graph format and saved in NetworkX (Graph-based in-memory DB). Similarly, this template can be modified or deleted as well. The functionality added here should have a corresponding set of API calls for users to perform these actions.
|
||||
|
||||
**Executing Templates**
|
||||
|
||||
When a change takes place in the Vitrage Graph, it informs the Evaluator Engine of the change. The engine will then search for templates relevant to this change and compare the pattern specified in each template to the new graph structure. For each pattern match found, execute the actions specified in the template.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
The templates are saved in NetworkX graph-base in memeory DB.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
The functionality added here for **managing** templates should have a corresponding set of API calls for users to perform these actions.
|
||||
|
||||
Versioning impact
|
||||
-----------------
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
None
|
||||
|
||||
Deployer impact
|
||||
---------------
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
None
|
||||
|
||||
Horizon impact
|
||||
--------------
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
TBD
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* API with Vitrage Graph
|
||||
* API with Vitrage Notifier
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
TBD
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
TBD
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
TBD
|
||||
89
specs/mitaka/vitrage-template-validator.rst
Normal file
89
specs/mitaka/vitrage-template-validator.rst
Normal file
@ -0,0 +1,89 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================
|
||||
Template Validator
|
||||
==================
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Tamplate 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
|
||||
------------
|
||||
A template editor that prevent invalid templates.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
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
|
||||
Loading…
Reference in New Issue
Block a user