Vitrage/RoadMap
目录
Vitrage 路线图
注意：以下任务的所有蓝图都可以在 Vitrage launchpad 上找到：https://blueprints.launchpad.net/vitrage
Pike 路线图
必须完成 – 设计于 Pike-1 完成 (4月14日)
- 持久化图形数据库
- 使用 TripleO 安装 Vitrage
- 与 Doctor 集成 – Apex 安装，测试脚本
- 告警推演用例
- 告警聚合
- Pike 目标（由 TC 定义）：验证 python 3.5
非常重要
- 注册 Vitrage 通知 API
- 用例仓库
- 获取 SNMP 告警？可能不需要（可以从 Zabbix 获取）
- 改进文档
重要
- 与 Mistral 集成
- 模板 CRUD
- 性能
- 改进模板语言（导入）
- 在 python-vitrageclient 中添加测试
Ocata 路线图
以下任务计划在 Ocata 中完成
- 与 Aodh 集成：在 Aodh 中创建 Vitrage 告警。这需要在 Aodh 中添加新的告警类型，请参阅：https://review.openstack.org/#/c/408060
- 新的 collectd-DPDK 数据源
- 支持在 TripleO 安装中作为 Vitrage
- 支持 Vitrage 作为 Doctor Inspector。包括
- 将 Vitrage 作为 OPNFV Apex 安装程序的一部分进行安装
- 支持 Doctor SB API
- 编写 Vitrage 的测试
- 重构静态数据源，使 yaml 文件结构与 Vitrage 模板 yaml 文件类似
- 重构 Vitrage ID
详细描述
持久化图形数据库
目前 Vitrage 持有基于 NetworkX 的内存图形数据库。如果 Vitrage 重新启动，则图形将基于不同数据源提供的信息重建。为了稳定性和支持 RCA 历史记录，我们希望引入一个持久化图形数据库作为 NetworkX 的替代方案（NetworkX 仍然可以为简单的部署和开发堆栈提供服务）。一个选项是 Neo4J，但也可以考虑其他图形数据库。
蓝图：https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph
评估器模板 CRUD
目前评估器模板在 Vitrage 初始化时加载。我们希望能够在不重新启动 Vitrage 的情况下在运行时编辑模板。
应该处理一些任务
- 添加模板的持久化存储
- 模板修改后，撤销原始模板并在图形中的所有相关顶点上运行新模板
蓝图：https://blueprints.launchpad.net/vitrage/+spec/crud-templates
此外，我们希望提供一个用于智能模板编辑的 UI，该 UI 还可以验证模板并帮助用户检测错误。
RCA 历史记录
目前 Vitrage 会删除停用的告警。一旦我们拥有持久化图形数据库，我们希望存储已删除的告警及其因果关系。然后，用户将能够检测到已经解决（或部分解决；例如，主机故障已修复，但运行在其一个实例上的应用程序未能恢复）的问题的根本原因。
有几个方面需要考虑
- 根本原因的表示逻辑。如果 A 导致 Z，那么 B 导致 Z，那么 A 停止了……如何表示它？
- 实现：存储一个大图是解决方案吗？根本原因关系也可以用其他方式存储
- UI 表示。如何在时间线上显示根本原因关系
蓝图：https://blueprints.launchpad.net/vitrage/+spec/rca-history
巴塞罗那设计峰会期间的讨论：https://etherpad.openstack.org/p/vitrage-barcelona-design-summit
实体图可用性
Horizon 中的 Vitrage 实体图显示了整个云拓扑的独特表示，从物理层（交换机、主机）到虚拟层（虚拟机）再到应用程序层（Heat 堆栈）。但是，当资源过多时，图形可能会变得过于拥挤。
这个问题在巴塞罗那设计会议上讨论过，并提出了一些建议。请参阅 https://etherpad.openstack.org/p/vitrage-barcelona-design-summit
