fix errors due to new validations
Change-Id: Ibf7f0974a7edb5452fb846391fd47bbcccc93667
This commit is contained in:
Idan Hefetz
parent
949be77bf7
commit
0998bfb071
@ -42,15 +42,6 @@ Implemented
|
||||
|
||||
specs/pike/implemented/*
|
||||
|
||||
Approved
|
||||
^^^^^^^^
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/pike/approved/*
|
||||
|
||||
Queens
|
||||
------
|
||||
|
||||
|
||||
@ -63,9 +63,8 @@ implements the three methods:
|
||||
* 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
|
||||
|
||||
@ -113,12 +113,12 @@ Collector plugin
|
||||
- samples OS services, Nagios, etc.
|
||||
- via each OS service REST API
|
||||
- method of collection:
|
||||
retrieve OS service elements list. For the purposes of:change
|
||||
notifications - as part of the periodic collection of the latest snapshot
|
||||
we'd use this method of collection against OS services which doesn't
|
||||
propagates change notification.run on its own collection subprocesses
|
||||
how to discover a change once a snapshot is collected, we'd like to know
|
||||
which entity was changed from the latest time a snapshot was taken in order
|
||||
retrieve OS service elements list. For the purposes of:change
|
||||
notifications - as part of the periodic collection of the latest snapshot
|
||||
we'd use this method of collection against OS services which doesn't
|
||||
propagates change notification.run on its own collection subprocesses
|
||||
how to discover a change once a snapshot is collected, we'd like to know
|
||||
which entity was changed from the latest time a snapshot was taken in order
|
||||
to enable this, we'd keep a baseline - a data structure which contains for each OS service entity (such as a vm instance), its ID + it latest collection timestamp or a hash which represents its latest state.by comparing the latest snapshot of elements against the baseline, we'd know for which entity we'd like to propagate a notification for.collect deltas for services which reveals this functionality for the purposes of change notifications this is the easy case, where change notifications are simply passed on to whoever registered for them
|
||||
- deployment - as a library
|
||||
|
||||
|
||||
@ -96,7 +96,8 @@ Each result describes the full validation (syntax and content) of one template f
|
||||
Response Examples
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"results": [
|
||||
{
|
||||
|
||||
@ -22,14 +22,18 @@ Proposed change
|
||||
===============
|
||||
|
||||
Aodh `update_method` in vitrage config file will be configured with:
|
||||
|
||||
/etc/vitrage/vitrage.conf
|
||||
```
|
||||
::
|
||||
|
||||
[aodh]
|
||||
update_method = push
|
||||
|
||||
Add a new notification topic in Aodh config file:
|
||||
|
||||
/etc/aodh/aodh.conf
|
||||
```
|
||||
::
|
||||
|
||||
[oslo_messaging_notifications]
|
||||
topics = vitrage_notifications
|
||||
|
||||
@ -77,8 +81,8 @@ performance improvement of getting Aodh alarms
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
** Config `update_method` as 'push' in `Aodh` section in vitrage config file.
|
||||
** Add the `vitrage_notifications` topic in `oslo_messaging_notifications`
|
||||
- Config `update_method` as 'push' in `Aodh` section in vitrage config file.
|
||||
- Add the `vitrage_notifications` topic in `oslo_messaging_notifications`
|
||||
section in Aodh config file.
|
||||
|
||||
Developer impact
|
||||
|
||||
@ -21,16 +21,15 @@ Proposed change
|
||||
===============
|
||||
|
||||
Here is a description, for each of the Vitrage APIs, how it should behave for each tenant:
|
||||
|
||||
Get alarms:
|
||||
1. Find all the alarms with the requested project_id (if the project is admin then show also alarms that has no project_id property)
|
||||
1. Find all the alarms with the requested project_id (if the project is admin then show also alarms that has no project_id property)
|
||||
2. Find all the resources with the requested project_id and return all the alarms that are attached to them.
|
||||
3. Merge the results from the previous steps and return it.
|
||||
|
||||
Get RCA:
|
||||
1. Find all the alarms that this alarm has caused, recursively. When reaching an alarm
|
||||
that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
|
||||
2. Find all the alarms that caused this alarm, recursively. When reaching an alarm that
|
||||
is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
|
||||
1. Find all the alarms that this alarm has caused, recursively. When reaching an alarm that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
|
||||
2. Find all the alarms that caused this alarm, recursively. When reaching an alarm that is not of same project_id (or on resource of same project_id), stop the recursion, including this last alarm in the response.
|
||||
3. Merge the results from the previous steps and return it.
|
||||
|
||||
Get Topology:
|
||||
|
||||
@ -24,7 +24,7 @@ has a lot of overlapping with the evaluator templates.
|
||||
|
||||
In static configuration, there are ``entities`` and their ``relationships``
|
||||
|
||||
.. highlight:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
- entities
|
||||
- {entity}
|
||||
@ -32,7 +32,7 @@ In static configuration, there are ``entities`` and their ``relationships``
|
||||
|
||||
In each entity
|
||||
|
||||
.. highlight:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
- name:
|
||||
id:
|
||||
@ -43,7 +43,7 @@ In each entity
|
||||
In evaluator templates we define: ``entities``, ``relationship`` and
|
||||
``scenarios``. Each scenario has a condition and actions.
|
||||
|
||||
.. highlight:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
- definitions
|
||||
- entities
|
||||
@ -171,4 +171,4 @@ New format of the template shall be documented.
|
||||
References
|
||||
==========
|
||||
|
||||
- `http://lists.openstack.org/pipermail/openstack-dev/2016-September/102678.html`_
|
||||
None
|
||||
@ -43,9 +43,9 @@ Datasources:
|
||||
- key / value tests : fix field names.
|
||||
- Transformers: No change is needed in the Transformers.
|
||||
- Processor: Checking if an entity exists in the graph: The entity is currently queried in the
|
||||
Graph according to its Vitrage ID. Instead, it will be queried according to the parameters set.
|
||||
If the entity exists, it’s original Vitrage ID will be used. Otherwise, a new UUID will be
|
||||
generated for vitrage ID via openstack UUIDUtils' generate_uuid.
|
||||
Graph according to its Vitrage ID. Instead, it will be queried according to the parameters set.
|
||||
If the entity exists, it’s original Vitrage ID will be used. Otherwise, a new UUID will be
|
||||
generated for vitrage ID via openstack UUIDUtils' generate_uuid.
|
||||
|
||||
|
||||
Update all necessary tests.
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
..
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
|
||||
@ -192,5 +192,5 @@ adding actions should be documented.
|
||||
|
||||
References
|
||||
==========
|
||||
.. [#first] https://wiki.openstack.org/wiki/Mistral
|
||||
.. [#second] https://docs.openstack.org/rally/latest/
|
||||
- https://wiki.openstack.org/wiki/Mistral
|
||||
- https://docs.openstack.org/rally/latest/
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user