跳转到： 导航, 搜索

NotificationSystem

总结

Nova 需要以尽可能接近实时的方式向用户提供通知。 建议的解决方案是实现一个 PubSubHubbub (PSH) 机制，Nova 将以标准的 Atom 1.0 格式创建通知，并通知 PSH hub，客户端订阅适当的通知以在有等待通知时接收更新。

PubSubHubbub (PSH) 是 Google 开发并维护在 http://code.google.com/p/pubsubhubbub/ 的开放协议。

Nova 不一定需要从头开始实现一个 hub，因为有几个可用的参考 hub。 但是，Nova 应该对现有的 hub 进行扩展/修改以支持内容访问控制。 具体来说，如果云在多个租户（项目、客户）之间共享，管理员可能不希望一个租户的通知对其他租户可用。 Nova 需要提供访问控制，以便一个租户（由“account number”字符串标识）无法访问其他租户。

发布说明

Nova 提供的 PubSubHubbub 参考 hub 包含一个开源 hub 以及允许身份验证以限制对某些数据的访问的访问控制。

原理

通过使用 PubSubHubbub (PSH)，Nova 可以将通知（例如，异常日志或使用数据）发布到一组订阅者，而无需为每个特定用例定义接口。 PubSubHubbub 是一种众所周知的开源标准，它基于现有的 IEF 技术（Atom）。 此外，通过确保通知采用标准格式，Nova 的用户可以通过许多现有技术（包括大多数现代 Web 浏览器）访问它们。 最后，由于 PSH 支持内容创建时的“ping”概念，这些通知可以以接近实时的基础进行传递。

用户故事

作为 Nova 管理员，我需要及时收到通知，以便能够响应紧急情况。

作为 Nova 管理员，我需要支持多种内容客户端，以便我无需使用我的资源来开发单独的接口。

作为系统集成商，我希望及时收到使用数据更新，并将这些数据分发给各种客户（包括内部和外部客户），用于计费、决策支持和分析目的。

前提条件

设计

通用要求

  1. 产生通知的服务或组件必须以 Atom 1.0 格式提供这些通知。
  2. 必须有一个中央配置设置，定义用于通知的零个或多个 hub。
  3. 如果为通知定义了至少一个 hub，则服务或组件 Atom feed 必须包含指向 hub 的链接：<link rel="hub" … />
  4. 如果为通知定义了至少一个 hub，则服务或组件应在有新的通知可用时通知 hub。 请参阅 http://code.google.com/p/pubsubhubbub/wiki/PublisherClients 以获取示例代码。
  5. PSH hub 必须根据 PSH 规范运行（可能不包括下面定义的访问控制）。
  6. <atom:content> 元素应该包含标准格式的结构化数据（从技术上讲，这是对生成通知的服务的一个要求；但是，通知服务应该验证 <content type=""> 是否有效）。

通用通知消息格式

所有消息由以下字段组成：message_id、publisher_id、event_type、priority 和 payload。 以下是每个字段的描述。

  • message_id - 在消息创建时生成的 UUID，用于区分消息。
  • publisher_id - 消息的来源 worker_type.host。
  • event_type - 事件的字面类型（例如，实例创建）。
  • priority - 遵循 Python 日志级别枚举集（DEBUG、WARN、INFO、ERROR、CRITICAL）。
  • payload - 一个 Python 字典的属性。 请注意，payload 可以包含任何 Python 数据类型，并且因 event_type 字段中的条目而异。
  • timestamp - 消息创建时刻的当前系统时间，以 UTC 格式。

组合消息将构建为上述属性的字典，然后通过驱动程序定义的传输机制发送。

消息示例

    {'message_id': str(uuid.uuid4()),
     'publisher_id': 'compute.host1',
     'timestamp': utils.utcnow(),
     'priority': 'WARN',
     'event_type': 'compute.create_instance',
     'payload': {'instance_id': 12, ... }}


Hub 开发

Nova 无需开发一个 hub 从头开始；已经实现了许多 hub，并且以开源格式提供。 此页面列出了一些可用的 hub 实现

http://code.google.com/p/pubsubhubbub/wiki/Hubs

访问控制

虽然 PSH 协议本身不支持访问控制（它当然旨在成为一个发布系统），但一些用户已经在其之上实现了 ACL。 Nova 应该在其选择的 hub 之上实现其中一种系统。

实施者应选择这些方法中的一种，最适合当前的 Nova 身份验证模式。

依赖项

多租户会计 - Hub 访问控制通过多租户规范中定义的 accountID 进行执行。

实现

为了分离关注点，并适应可能不需要或不希望通知流量的用户，nova 通过可配置的通知驱动程序发出通知。 默认情况下，nova 使用 no_op 驱动程序，该驱动程序只是忽略通知。 可以使用 --notification_driver 标志选择驱动程序。

可以使用 log_notifier 驱动程序（--notification_driver=nova.openstack.common.notifier.log_notifier）将通知发送到 Nova 的日志输出。

对于此规范的完整实现，通知会使用 rabbit_notifier 驱动程序（--notification_driver=nova.openstack.common.notifier.rabbit_notifier）发送到一组 AMQP 队列。 外部应用程序，例如 Yagi 监视这些队列，并负责以 Atom 格式格式化通知，创建 feed，并可选地，ping 一个 PubSubHubbub Hub，和/或通过 Atom Pub 将通知发布到其他系统。 通知以 json 格式发布到 "nova" exchange 下的 topic 队列，topic 命名方式为 "notifications.info"，其中第一部分是 topic 前缀（默认情况下为 "notifications"，但可以通过 --notification_topic 标志设置），第二部分是优先级（"debug"、"info"、"warn"、"critical" 或 "error"）。 发布到多个队列是为了防止大量的低优先级通知延迟处理高优先级通知。

Nova 当前发出关于错误的通知，例如实例构建失败，以及 SystemUsageData 用于使用情况跟踪。

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。

从 "https://wiki.openstack.org/w/index.php?title=NotificationSystem&oldid=17781" 检索