Delete the external-actions.rst file, it belongs in the vitrage-specs project
Change-Id: Ibc370a49d1d56ebcad834b2d449b4c607b8374e7
This commit is contained in:
Ifat Afek
parent
a503147045
commit
0894e673e7
@ -1,197 +0,0 @@
|
|||||||
..
|
|
||||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
|
||||||
License.
|
|
||||||
|
|
||||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
||||||
|
|
||||||
=============================================
|
|
||||||
Support External Actions in Vitrage Templates
|
|
||||||
=============================================
|
|
||||||
|
|
||||||
launchpad blueprint:
|
|
||||||
https://blueprints.launchpad.net/vitrage/+spec/support-external-actions
|
|
||||||
|
|
||||||
Currently, the Vitrage templates support the following actions: raise alarm,
|
|
||||||
set state, mark causal relationship and mark-down.
|
|
||||||
The implementation of mark-down is patchy (update a property on the vertex and
|
|
||||||
call the notifier).
|
|
||||||
|
|
||||||
We need a way to define in the template an external action that should be
|
|
||||||
taken. One example is the mark-down. Another example is to execute a Mistral
|
|
||||||
workflow or a Congress policy.
|
|
||||||
|
|
||||||
Problem description
|
|
||||||
===================
|
|
||||||
|
|
||||||
The following use cases should be supported:
|
|
||||||
|
|
||||||
1. **mark-down**. This is an existing use case. If a mark-down action exists,
|
|
||||||
Vitrage will call Nova mark-down API. The behavior should remain the same
|
|
||||||
after the change.
|
|
||||||
2. **Execute a Mistral workflow**. The user should be able to execute a Mistral
|
|
||||||
workflow based on Vitrage insights.
|
|
||||||
3. **Execute other external actions**, like a Congress policy.
|
|
||||||
|
|
||||||
Proposed change
|
|
||||||
===============
|
|
||||||
|
|
||||||
Add a new action for each external engine we would like to support. The action
|
|
||||||
will have metadata with parameters to be sent to the engine.
|
|
||||||
|
|
||||||
Examples
|
|
||||||
--------
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
action:
|
|
||||||
action_type: execute_nova
|
|
||||||
metadata:
|
|
||||||
api_call: mark-down
|
|
||||||
host: host1
|
|
||||||
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
action:
|
|
||||||
action_type: execute_mistral
|
|
||||||
metadata:
|
|
||||||
workflow: evacuate_host
|
|
||||||
failed_host: host1
|
|
||||||
|
|
||||||
|
|
||||||
The idea behind adding a new external_* action for each engine is to emphasize
|
|
||||||
that Vitrage supports a predefined set of external actions, and specifically
|
|
||||||
it does not support runinng scripts.
|
|
||||||
|
|
||||||
The internal implementation will be identical for Nova, Mistral, Congress, etc.
|
|
||||||
During the template loading phase, the execute_* action will be converted to
|
|
||||||
a generic Execute action, with a notifier parameter. The template validator
|
|
||||||
will verify that the wanted notifier is enabled in vitrage.conf, otherwise
|
|
||||||
the template loading will fail.
|
|
||||||
|
|
||||||
When executing the Execute action, the evaluator will send an event to the
|
|
||||||
message bus of the wanted notifier. This way, only the Mistral notifier will
|
|
||||||
handle the execute_mistral actions.
|
|
||||||
|
|
||||||
Note that currently only the Vitrage graph sends notification to the notifier.
|
|
||||||
This behavior will be changed, so notifications will be sent both from the
|
|
||||||
graph (for deduced alarms and set state) and from the evaluator.
|
|
||||||
|
|
||||||
|
|
||||||
Alternatives
|
|
||||||
------------
|
|
||||||
|
|
||||||
There are two alternatives:
|
|
||||||
|
|
||||||
Send Message bus notifications
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
Vitrage can have a message bus notifier, that will send notifications about
|
|
||||||
raise/delete alarm, set state and mark causal-relationship. Mistral will be
|
|
||||||
configured to execute certain workflows based on the notifications received
|
|
||||||
from Vitrage.
|
|
||||||
|
|
||||||
Advantages:
|
|
||||||
|
|
||||||
* No extra configuration needed in Vitrage
|
|
||||||
* Can work with the current notifiers mechanism
|
|
||||||
|
|
||||||
Disadvantages:
|
|
||||||
|
|
||||||
* Messgae bus notifications might get lost
|
|
||||||
* Less powerful. In Vitrage template the user can decide to execute a workflow
|
|
||||||
based on a combination of alarms or a specific topology. Once Mistral gets
|
|
||||||
the notifications, the topology context is no longer there.
|
|
||||||
* mark-down use case is not supported by this solution
|
|
||||||
|
|
||||||
Configuration Done on the specific notifier
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
A Mistral notifier will be written and receive notifications from the graph.
|
|
||||||
It will be configured by a yaml file that will determine which workflow to
|
|
||||||
execute per specific alarm.
|
|
||||||
|
|
||||||
Advantages:
|
|
||||||
|
|
||||||
* No extra configuration needed in Vitrage
|
|
||||||
* Can work with the current notifiers mechanism
|
|
||||||
* No lost messages
|
|
||||||
|
|
||||||
Disadvantages:
|
|
||||||
|
|
||||||
* Less powerful. In Vitrage template the user can decide to execute a workflow
|
|
||||||
based on a combination of alarms or a specific topology. In Mistral notifier
|
|
||||||
we no longer have this context.
|
|
||||||
* mark-down use case is not supported by this solution
|
|
||||||
|
|
||||||
|
|
||||||
Data model impact
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
A new Execute action will be added to the evaluator.
|
|
||||||
|
|
||||||
REST API impact
|
|
||||||
---------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Versioning impact
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
We should introduce a versioning mechanism to the templates. This will be done
|
|
||||||
when modifying the implementation of mark-down.
|
|
||||||
|
|
||||||
Other end user impact
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Deployer impact
|
|
||||||
---------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Developer impact
|
|
||||||
----------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Horizon impact
|
|
||||||
--------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
|
|
||||||
Implementation
|
|
||||||
==============
|
|
||||||
|
|
||||||
Assignee(s)
|
|
||||||
-----------
|
|
||||||
|
|
||||||
Primary assignee:
|
|
||||||
ifat-afek
|
|
||||||
|
|
||||||
Work Items
|
|
||||||
----------
|
|
||||||
|
|
||||||
* Enhance the template language (template loading and validation)
|
|
||||||
* Update the documentation
|
|
||||||
* Execute the external actions from the evaluator
|
|
||||||
|
|
||||||
Dependencies
|
|
||||||
============
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Testing
|
|
||||||
=======
|
|
||||||
|
|
||||||
The implementation will be covered by unit tests and tempest tests.
|
|
||||||
|
|
||||||
Documentation Impact
|
|
||||||
====================
|
|
||||||
|
|
||||||
The new action should be documented
|
|
||||||
|
|
||||||
References
|
|
||||||
==========
|
|
||||||
|
|
||||||
None
|
|
||||||
Loading…
Reference in New Issue
Block a user