Define and handle equivalence among entities
Co-Authored-By: Idan Hefetz <idan.hefetz@nokia.com> Co-Authored-By: Ifat Afek <ifat.afek@nokia.com> Change-Id: Ida7d8293fce580fea0501b86c0fd5502e22f86a0 Implement: blueprint entity-equivalence
This commit is contained in:
Yujun Zhang
parent
5ea32d38cb
commit
27fa2274ce
247
specs/pike/entity-equivalence.rst
Normal file
247
specs/pike/entity-equivalence.rst
Normal file
@ -0,0 +1,247 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
============================================
|
||||||
|
Define and handle equivalence among entities
|
||||||
|
============================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/vitrage/+spec/entity-equivalence
|
||||||
|
|
||||||
|
Define equivalence among entities to allow mapping two or more entities to same
|
||||||
|
object and handle it properly in scenario evaluator. It is inspired by Idan
|
||||||
|
Hefetz's proposal about `ZTE use case of alarm deduction`_, but designed in a
|
||||||
|
generic way to allow extending to RESOURCE equivalence in future.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Introducing entity equivalence will enhance the extensibility of Vitrage,
|
||||||
|
making it suitable for more use cases, such as
|
||||||
|
|
||||||
|
- early `deduction`_ of alarm before it is reported and deal with the real
|
||||||
|
alarm followed
|
||||||
|
- `aggregation`_ of equivalent alarms from multiple monitors
|
||||||
|
- aggregation of resource information from multiple data sources.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Add a new file (or a set of files) that define equivalence between entities
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
metadata:
|
||||||
|
name: entity equivalence example
|
||||||
|
equivalences:
|
||||||
|
- equivalence:
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: nagios
|
||||||
|
name: host_problem
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: zabbix
|
||||||
|
name: host_problem
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: vitrage
|
||||||
|
name: host_problem
|
||||||
|
- equivalence:
|
||||||
|
...
|
||||||
|
|
||||||
|
These definitions will take effect globally, i.e. for every other template
|
||||||
|
|
||||||
|
The evaluator will duplicate every scenario for every equivalent alarm
|
||||||
|
automatically. For example, in case of the condition:: yaml
|
||||||
|
|
||||||
|
condition: nagios_host_problem_on_host and host_contains_vm``
|
||||||
|
|
||||||
|
Two conditions will be created internally:: yaml
|
||||||
|
|
||||||
|
condition: nagios_host_problem_on_host and host_contains_vm
|
||||||
|
condition: zabbix_host_problem_on_host and host_contains_vm
|
||||||
|
condition: vitrage_host_problem_on_host and host_contains_vm
|
||||||
|
|
||||||
|
The idea is that the user will write a single condition, and all equivalent
|
||||||
|
conditions will be created and evaluated automatically.
|
||||||
|
|
||||||
|
Equivalences should be defined explicitly. Including one entity in two or more
|
||||||
|
equivalence definition will result in implicit chaining, thus is considered
|
||||||
|
invalid. For example, if ``a eq b`` and ``b eq c`` are defined separately, it
|
||||||
|
will logically result in an implicit ``a eq c``. This will introduce unnecessary
|
||||||
|
complexity in creating templates and should be restricted in validator.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Separate file vs embedded definition
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Instead of creating a separate file, we may embed the equivalence definitions in
|
||||||
|
templates by adding a new section ``equivalences``. Entities that are equivalent
|
||||||
|
to each other are grouped in arrays of their ``template_id``
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
metadata:
|
||||||
|
name: entity equivalence example
|
||||||
|
definitions:
|
||||||
|
entities:
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: nagios
|
||||||
|
name: host_problem
|
||||||
|
template_id: nagios_host_problem
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: zabbix
|
||||||
|
name: host_problem
|
||||||
|
template_id: zabbix_host_problem
|
||||||
|
- entity:
|
||||||
|
category: ALARM
|
||||||
|
type: vitrage
|
||||||
|
name: host_problem
|
||||||
|
template_id: vitrage_host_problem
|
||||||
|
...
|
||||||
|
relationships:
|
||||||
|
...
|
||||||
|
equivalences:
|
||||||
|
- [nagios_host_problem, zabbix_host_problem, vitrage_host_problem]
|
||||||
|
scenarios:
|
||||||
|
...
|
||||||
|
|
||||||
|
In this way, there will be fewer duplication of entity definitions.
|
||||||
|
|
||||||
|
However, given the fact that once an ``equivalent`` edge is added between two
|
||||||
|
alarms, then it *logically* means that they are equivalent in *all* other
|
||||||
|
templates as well. Even if they are not specified this way in the other
|
||||||
|
templates. Then template will be less clear without the equivalence information
|
||||||
|
embedded in it.
|
||||||
|
|
||||||
|
The duplication of entity definition might be resolved by implementing an
|
||||||
|
``import`` feature in other blueprint.
|
||||||
|
|
||||||
|
Adding equivalent edge vs not
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
``equivalent`` edges could be created between every two equivalent alarms.
|
||||||
|
Since all related scenarios have been duplicated, This does not bring extra
|
||||||
|
value in the evaluator.
|
||||||
|
|
||||||
|
The ``equivalent`` edge could be useful for future evolution such as alarm
|
||||||
|
aggregation, UI optimization, alarm deduction. It may be implemented in those
|
||||||
|
blueprints.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Versioning impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Deployer impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Horizon impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
There are currently three views in ``vitrage-dashboard``
|
||||||
|
|
||||||
|
Topology view
|
||||||
|
^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
No impact
|
||||||
|
|
||||||
|
RCA view
|
||||||
|
^^^^^^^^
|
||||||
|
|
||||||
|
More alarms and more ``causes`` edges
|
||||||
|
|
||||||
|
.. TODO:: (yujunz) include example graph
|
||||||
|
|
||||||
|
Entity graph
|
||||||
|
^^^^^^^^^^^^
|
||||||
|
|
||||||
|
- separate vertices for equivalent alarms (nagios, zabbix, vitrage)
|
||||||
|
- more edges (``equivalent`` and ``on``)
|
||||||
|
|
||||||
|
Summary
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
The impacts on RCA view and Entity graph will only be relevant to cases where
|
||||||
|
both ``equivalence`` and ``vitrage-dashboard`` are used. We will handle it in
|
||||||
|
future blueprints.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
yujunz
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
None
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- validate and parse equivalence definition in templates
|
||||||
|
- duplicate scenarios in the scenario repository
|
||||||
|
- no changes in sub-graph matching or the evaluator
|
||||||
|
|
||||||
|
The following items are not in scope
|
||||||
|
|
||||||
|
- aggregation of equivalent alarms
|
||||||
|
- ``add-equivalent`` action
|
||||||
|
- support alarm equivalence in UI
|
||||||
|
- implement causal tree model for alarm deduction enhancement
|
||||||
|
- resource equivalence
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
The implementation will be covered by additional unit test
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
- documentation on how to define equivalence and when to use it
|
||||||
|
- declare limitation on resource equivalence
|
||||||
|
- list known issues when use ``equivalence`` with ``vitrage-dashboard``
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. _ZTE use case of alarm deduction: https://goo.gl/FfDLi8
|
||||||
|
.. _deduction: https://review.openstack.org/#/c/423000/
|
||||||
|
.. _aggregation: https://blueprints.launchpad.net/vitrage/+spec/alarm-aggregation
|
||||||
Loading…
Reference in New Issue
Block a user