拆分 Ceilometer 告警¶
https://blueprints.launchpad.net/ceilometer/+spec/split-ceilometer-alarming
Ceilometer 从最初的简单计量数据收集组件发展到包含许多不同组件,执行不同的功能。存储层在 Juno 和 Kilo 期间已被抽象化,并将由 Gnocchi 处理。本规范建议继续进行这项工作,将 Ceilometer 的告警子系统拆分为一个自主组件,与 Ceilometer 的其余部分和 Gnocchi 相连接。
这将有助于代码审查、维护、部署、升级……拥有几个小型面向服务的组件来管理,将比管理单个单体项目更容易。
问题描述¶
目前,Ceilometer 的功能可以分为不同的组件,主要包括
计量数据轮询和事件存储 (Ceilometer 轮询和通知代理以及收集器)
计量数据存储 (Gnocchi)
告警评估和触发
这三个组件目前合并在一个代码库和仓库中,而它们实际上是相互通信的不同服务。这导致在深入研究项目时,代码和架构变得有些混乱。
提议的变更¶
我们希望通过将告警子系统从 Ceilometer 主仓库中拆分出来,并使其在自己的仓库中独立运行,来改进项目管理、代码审查、升级等。
新的仓库和项目将被命名为 aodh。
替代方案¶
什么都不做,继续扩展项目,直到它崩溃。
数据模型影响¶
主要的数据模型影响是将告警存储在与样本和事件不同的数据库中。此更改已在 Juno 中实现。
REST API 影响¶
告警 API 不应更改,并继续包含在 /v2/alarms 中。但是,ceilometer-api 端点和守护进程将被替换为仅实现告警子系统的特定 REST API 守护进程。这意味着需要创建一个新的 Keystone 端点并进行注册。
我们还将提供有关如何支持配置可以路由请求到 Ceilometer API 端点或新的告警 API 端点的代理的文档。
安全影响¶
无
Pipeline 影响¶
无
其他最终用户影响¶
如上所述,这将需要一个新的 Keystone 端点来操作告警。
性能/可扩展性影响¶
如果需要,可以很容易地设想更好的可扩展性。仅针对告警的 API 端点更容易扩展。此外,由于告警代码库可能更小,性能可能会略有提高。
其他部署影响¶
告警子系统在成为自己项目/仓库的一部分时使用的配置文件应从 ceilometer.conf 中拆分出来。这意味着应该创建一个新的配置文件,但它应该与当前的 ceilometer.conf 文件类似。
除此之外,不应添加或删除任何选项。
守护进程将保持不变,API 将以相同的方式部署——通过(新的)守护进程或推荐的 WSGI 接口。
子系统将独立于 Ceilometer 发布,按照自己的时间表发布,就像 Gnocchi 和现在其他 OpenStack 项目一样。每个周期结束时也会进行协调发布。
开发者影响¶
新的代码仓库,用于托管 Ceilometer 告警,需要一个新的核心审查团队,该团队将由当前的 ceilometer-core 审查人员的副本组成。
实现¶
负责人¶
- 主要负责人
jdanjou
工作项¶
将 Ceilometer 告警代码库从 Ceilometer 的其他部分隔离出来。
创建一个新的 Python 包和仓库,其中包含该隔离的代码库。
将此仓库发布为 openstack/<projectname>
启用 Tempest、devstack、grenade 等测试
从 Ceilometer 中弃用告警代码
Liberty 之后:从 Ceilometer 中删除告警代码
为下游切换工作做出贡献,以迁移现有的 Fedora/Deb 包和 puppet 模块。
未来生命周期¶
这个 Ceilometer 子项目将能够像其他 OpenStack 项目/组件一样独立发布。
如果项目同意不进行弃用期,则可以删除工作项 4。否则,核心审查人员必须小心,确保没有代码更改/修复合并到 Ceilometer,而是合并到新的仓库中。
依赖项¶
无
测试¶
测试覆盖率应保持不变,使用单元测试和使用 Tempest 的功能测试。
文档影响¶
文档需要更新,以包含这个新组件,而不是当前的 Ceilometer 告警。