Vitrage/RoadMap
Note: all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage
Contents
Plans for Ocata
The following tasks are planned for Ocata
- Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060
- New collectd-DPDK datasource
- Support Vitrage as part of TripleO installation
- Support Vitrage as Doctor Inspector. Including
- Installing Vitrage as part of OPNFV Apex installer
- Supporting Doctor SB API
- Writing tests for Vitrage
- Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files
- Refactoring Vitrage ID
Backlog
Persistent Graph Database
Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well. Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph
RCA History
Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), There are a few aspects to consider: The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it? Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well UI representation. How to display the root cause relationship on a time line Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit
Entity Graph Usability
Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit
Evaluator Templates CRUD
Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage. A few tasks should be handled: Add a persistent storage for the templates Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates
In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.
Other tasks
Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications
