滚动升级¶
https://blueprints.launchpad.net/ceilometer/+spec/rolling-upgrades
随着 Ceilometer 在每个迭代中不断成熟并添加新功能，用户需要升级他们现有的环境，同时最大限度地减少所需的潜在停机时间。
问题描述¶
Ceilometer 当前提供 4 个离散的服务：轮询代理、通知代理、收集器服务和 API 服务。它们各自提供自己的功能，并且数据流和每个组件的目的通常容易在升级服务时被操作员遗忘。
为了确保流畅的升级体验，我们需要正确描述组件的升级路径。
提议的变更¶
幸运的是，由于 Ceilometer 的单向设计，工作完成并移交时无需担心，因此升级实际上是一个简单的过程，只需要正确的升级顺序。
使用“绝不删除，绝不更改，只添加”的简单原则，我们可以确保新的模式更改能够被旧的和新的消费者理解。
有两种升级路径需要处理——两者都不需要代码更改
服务的完全升级
数据库使用上述原则进行升级。
必须首先将收集器下线。然后可以启动了解如何解释新负载的新收集器。它将忽略任何历史属性。
然后可以下线并升级通知代理，条件相同。
可以下线并升级轮询代理。在这种路径中，您需要在启动之前先关闭所有主机的代理。启动第一个代理后，您应该验证数据是否再次被轮询。
可以在任何时候下线并升级 API 服务。
服务的部分升级
数据库使用上述原则进行升级。
新的收集器服务可以与旧的收集器一起启动，并且必须了解如何解释新的负载。它将忽略任何历史属性。
如果未启用 workload_partioning，或者具有相同的管道配置，则新的通知代理可以与旧的代理一起启动。否则，必须首先将旧的代理加载相同的管道配置，以确保所有通知代理都使用相同的管道集。
只有在没有添加新的轮询器的情况下，新的轮询代理才能与旧的代理一起启动。否则，新的轮询代理必须仅在其自己的分区组中启动，并且仅轮询新的轮询器。在升级所有旧的代理之后，轮询代理可以更改为轮询新的轮询器和旧的轮询器。
API 服务管理由 WSGI 处理，因此始终只有一个版本的 API 服务正在运行
注意
在部分升级路径中，升级顺序无关紧要。唯一的要求是首先升级数据库。建议按照当前描述的相同顺序进行升级：数据库、收集器、通知代理、轮询代理、API。
关于新模型，它们将被推送到自己的唯一队列中，类似于今天事件和样本在完全独立的队列上处理的方式。
上述过程将被添加到 OpenStack 文档中。
替代方案¶
oslo.versionedobjects - 这似乎过于复杂，并且会为每个样本增加处理开销
版本化队列 - 这没有 o.vo 开销，但需要更多的内存来处理额外的队列。
版本化负载 - 这可以简化负载，因为我们不需要携带历史字段，但需要代理了解每个唯一的版本
数据模型影响¶
根据更改量，这可能会增加模型的大小，因为我们需要捕获旧的属性。如果出现问题，我们可以选择定义一个放弃周期，停止支持 EOL 构建中的属性。
REST API 影响¶
无。
安全影响¶
无。
Pipeline 影响¶
无。
其他最终用户影响¶
无。
性能/可扩展性影响¶
相同的处理量，但可能更大的负载。
其他部署影响¶
对于不从 API 消费数据的用户，如果他们想要最新的版本，他们需要了解模型更改。
开发者影响¶
无。
实现¶
负责人¶
- 主要负责人
gordc
- 持续维护者
所有人
工作项¶
将上述条件添加到文档中
添加测试支持
未来生命周期¶
如果服务要求发生变化，上述假设可能不足以满足要求。
依赖项¶
无。
测试¶
多节点手榴弹测试
文档影响¶
这个提案仅仅是文档。
参考资料¶
[1] https://etherpad.openstack.org/p/mitaka-telemetry-upgrades
