Pike Series Release Notes


New Features

  • A new vitrage-collector service was added, in order to separate the datasource loading from the Vitrage graph processing. This change allows better HA support and will enable storing the datasources events in a database in order to support alarm history.

  • Vitrage now supports authentication with KeyCloak server using OpenId Connect protocol.

  • A new service was added to Vitrage, the machine learning service. Together with it, the first machine learning plugin was added - the Jaccard Correlation plugin. This plugin listens to rabbit MQ receiving messages about creation and deletion of alarms, and learns the correlation between each pair of alarms, in order to recommend on creation of new templates in the future.

  • Integration with Mistral (the OpenStack workflow service). The Vitrage user can specify in a Vitrage template that if a certain condition is met (like an alarm on the host, or a combination of a few alarms) a Mistral workflow should be executed. The workflow can be used, for example, to take corrective actions.


New Features

  • Added osprofiler support. OSProfiler is an OpenStack cross-project profiling library. It allows the user to generate a trace per request which is processed in multiple services, and then generate a tree of calls which is intuitive to understand.


New Features

  • A new SNMP notifier was added, in order to send SNMP traps from Vitrage. SNMP traps will be sent to signed up targets, when Vitrage deduced alarm is raised. This notifier allows to listen to alarms raised by Vitrage. The new notifier is pluggable so anyone can add an implementation.

  • The Vitrage ID feature is a change in the way we create an entity Vitrage ID. Instead of The ID being created as a concatenation of different entity fields, it is a standard openstak UUID generation. This also allows future history support.

  • Support definition of entity equivalence. If the equivalence between A and B is configured, all scenarios linked to entity A will be expanded to equivalent scenarios, i.e. same conditions and actions with the referenced entity A replaced by entity B. One use case of equivalence is treating equivalent alarms from multiple data source as the same, but no need for duplicating scenario definition in templates.

  • The Multi Tenancy feature allows different tenants to see their own entities for each api command. The feature allows admin to add the --all-tenants parameter in order to see all the entities for that api command.

  • The Not Operator feature adds support of the not operator to the templates language in addition to and and or operators. The not operator allows scenarios such as - - Support of High Availability scenarios - Support of negative scenarios, for example - raise an alarm on host that has no cpu_alarm on it.