声明式通知处理¶
https://blueprints.launchpad.net/ceilometer/+spec/declarative-notifications
本规范的目标是提出一种更声明式的方法来定义通知事件。
问题描述¶
现有的通知处理实现存在各种限制。本提案解决的问题包括
无法选择性地监听感兴趣的特定事件主题。
捕获感兴趣的通知不应需要代码更改。
添加新的事件交换机涉及相同的例行代码更改。代码重复过多。
需要比需要的更多地了解代码库
更优雅的交换机控制
本提案采用更声明式的方法来解决这些问题。
提议的变更¶
首先，我们定义一个通知事件模板，其中设置事件签名和属性。这是一个简单的 yaml 文件，格式如下
---
resources:
- name: image
type: "gauge"
topics:
- "image.size"
volume: payload.size
unit: B
counter_name: image.size
tenant_id: payload.tenant_id
user_id: payload.user_id
instance_id: payload.instance_id
这本质上描绘了我们在 notifications.py 中添加的样板代码。基本的通知处理程序加载事件定义并执行调用 process_notifications 和生成样本的初步步骤。优势在于，未来当需要添加新事件时，最终用户只需更新 yaml 文件即可。
另请注意，我们正在逐步淘汰存在计量器。所有当前的存在计量器都将放在模板文件的底部，并附带说明，说明它们将在“M”版本中删除。
其次，我们需要优雅地处理此定义中的交换机控制。交换机在 ceilometer.conf 中指定
我们已经在 ceilometer.conf 中定义了交换机。我们可以按原样利用这些交换机，并假设如果定义了这些交换机，我们将启用它们。我们还可以添加一个新选项来指定我们希望允许的所有交换机，交换机名称与定义的名称相同。这些交换机将由基本通知处理程序读取，get_targets 逻辑将循环遍历允许的交换机并设置交换机。如果事件名称是交换机名称的一部分，我们将跳过处理这些通知并继续。
替代方案¶
我们可以利用现有的 event_definition.yaml 用于转换。但我不太确定它是否足够自由和灵活。我对此想法持开放态度。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
Pipeline 影响¶
无
其他最终用户影响¶
无
性能/可扩展性影响¶
无
其他部署影响¶
无
开发者影响¶
无
实现¶
负责人¶
- 主要负责人
Pradeep Kilambi <pkilambi@redhat.com>
- 其他贡献者
Pradeep Kilambi <pkilambi@redhat.com>
工作项¶
工作项：* 定义事件通知模板 * 实现通用通知处理程序以处理模板并生成样本 * 添加对处理交换机控制的支持 * 清理现有处理程序 * 添加和更新测试覆盖率
未来生命周期¶
无
依赖项¶
无
测试¶
添加单元测试覆盖
文档影响¶
通过模板文件和示例记录启用通知事件和交换机的新方法。
