支持 oslo 消息通知中的传输方式

https://blueprints.launchpad.net/oslo.messaging/+spec/support-transports-per-oslo-notifications

在拥有多个区域的大型云环境中，运维人员通常会将全局组件（例如：Designate、Ceilometer）配置为容灾 (DR) 方式。然后，核心服务（如 Nova 和 Neutron）被配置为将 oslo.messaging 通知发送到基于区域的组件（例如：Searchlight）以及全局组件。目前，oslo.messaging 仅允许将所有通知发送到一个底层的消息传输（例如：一个部署了基于区域组件的 rabbitmq 集群）。本规范建议在 oslo.messaging 中添加功能，允许运维人员为每个通知定义不同的 transport_url，以便它们可以被发送到不同的消息传输（例如：rabbitmq 集群）。

问题描述

oslo.messaging 允许在每个组件的配置文件中指定驱动程序和通知传输，如下所示。例如，在 nova 中。

[oslo_messaging_notifications]
driver = messaging
topics = notifications,notifications_designate
transport_url = rabbit://username:password@rabbit001.com:5672

使用上述配置，与 notifications 和 notifications_designate 相关的通知将被发送到定义的 transport_url 到 rabbit001.com。如果 designate 服务部署到使用不同 rabbitmq 集群的不同区域/集群，目前没有办法仅将 notifications_designate 发送到例如 rabbit002.com，即 designate 服务 rabbitmq 集群。

应该允许根据 transport_url per notification 将通知发送到不同的底层消息传输。

提议的变更

本规范建议遵循 Cinder [1] 和 Glance [2] 组件中完成的 enabled_backends 的相同实现。

为每个通知定义动态的新配置组

例如

[oslo_messaging_notifications]
driver = messaging
topics = notifications,notifications_designate,any_other_notification
transport_url = rabbit://username:password@rabbit001.com:5672

[oslo_messaging_topic_notifications]
transport_url = rabbit://username:password@rabbit001.com:5672

[oslo_messaging_topic_notifications_designate]
transport_url = rabbit://username:password@rabbit002.com:5672

如上述配置部分所述，[oslo_messaging_notifications] 部分包含用于通知的 topics 列表。然后，每个通知都会动态地分组，并拥有自己的 transport_url。基于主题的部分的格式将是 oslo_messaging_topic_<topic-name>，以避免主题名称与其他配置部分名称之间的冲突。

默认情况下，如果任何通知未定义 transport_url，它将回退到主部分的 transport_url [oslo_messaging_notifications]，如果也在那里定义了 transport_url，则最终回退到 [oslo_messaging_rabbit] 中定义的 transport_url。在上面的示例中，notifications 主题使用 rabbit001.com rabbitmq 集群。notifications_designate 使用 rabbit002.com rabbitmq 集群，而 any_other_notification 使用 rabbit001.com rabbitmq 集群。

通知将继承所有其他配置选项值，例如 driver 等。

此更改是向后兼容的，因此即使运维人员未指定每个通知的 transport_url，它们也会回退到主部分。

此更改不需要对 oslo.config 进行任何更改，因为所有内容都已经支持。

如果不想将通知发送到不同的集群，此更改也不需要像 Nova、Neutron 这样的客户端更改其配置文件。

备选方案

可以使用以下新功能实现此用例

  1. 在 oslo.conf 中添加 MultiOptGroup 支持，与 MultiOpt 相同。

  2. 在 oslo.messaging 以及 Nova 和 Neutron 这样的客户端中使用 MultiOptGroup

例如

[oslo_messaging_notifications]
driver = messaging
topics = notifications
transport_url = rabbit://username:password@rabbit001.com:5672

[oslo_messaging_notifications]
driver = messaging
topics = notifications_designate
transport_url = rabbit://username:password@rabbit002.com:5672

[oslo_messaging_notifications]
driver = messaging
topics = any_other_notification
transport_url = rabbit://username:password@rabbit001.com:5672

此解决方案需要在 oslo.config 中添加一项新功能，该功能将允许像上面那样多次定义选项组，这可用于在 oslo.messaging 中定义每个通知的 transport_url。此功能在其他需要多次定义组的用例中也可能很有用。

另一种替代方案是使用 RabbitMQ Shovel 插件（如果将 rabbitmq 用作消息传递后端）将消息从一个集群移动到另一个集群。您可以为每个 notification 定义单独的 shovel 策略，并使用不同的 dest-uri 将它们发送到不同的 rabbitmq 集群。使用 shovel 方法的一个缺点是 RabbitMQ shovel 插件实际上会创建一个不存在的队列，作为 RabbitMQ 节点上的持久队列，因为那是 Shovel 插件的行为。如果 OpenStack 服务未使用持久队列，该服务将无法将消息发送到 rabbitmq，并给出以下错误：Error: Queue.declare: (406) PRECONDITION_FAILED

Impact on Existing APIs

没有影响。

安全影响

没有影响。

性能影响

没有影响。

Configuration Impact

每个通知将拥有自己的组，可以像上面那样定义。

开发人员影响

没有影响。

Testing Impact

需要额外的单元测试来涵盖添加的功能。

实现

负责人

主要负责人

Dinesh_Bhor (bhordinesh07@gmail.com)

其他贡献者

志愿者？

里程碑

..TODO(Dinesh_Bhor): 弄清楚

工作项

  • 实现新的动态 notifications OptGroup 生成。

  • 将其集成到 get_notifications_transport 和 Notifier 类中。

  • 更新文档。

  • 更新示例配置生成器以包含变量名。

  • 更新文档生成器以包含变量名。

孵化

N/A

文档影响

需要更新文档，以指示可以使用其自己的专用组覆盖通知选项。

依赖项

N/A

参考资料