Difference between revisions of "Vitrage/RoadMap"
(Created page with "'''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage == Plans for Ocata == The following tasks are plann...") |
|||
| Line 1: | Line 1: | ||
| + | = Vitrage Road Map = | ||
| + | |||
'''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage | '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage | ||
== Plans for Ocata == | == Plans for Ocata == | ||
The following tasks are planned 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 | * 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 | * New collectd-DPDK datasource | ||
| Line 18: | Line 21: | ||
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. | 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. | 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 | Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph | ||
=== RCA History === | === 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), | 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: | 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? | + | * 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 | + | * 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 | + | * UI representation. How to display the root cause relationship on a time line |
| + | |||
Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history | Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history | ||
A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit | A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit | ||
| Line 31: | Line 37: | ||
=== Entity Graph Usability === | === 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. | 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 | 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 === | === 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. | 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: | A few tasks should be handled: | ||
| − | Add a persistent storage for the templates | + | * 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 | + | * 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 | Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates | ||
| Line 43: | Line 52: | ||
=== Other tasks === | === Other tasks === | ||
| − | Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu | + | * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu |
| − | Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications | + | * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications |
Revision as of 07:31, 14 December 2016
Contents
Vitrage Road Map
Note: all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage
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
