Service Version Behavior Changes¶
https://blueprints.launchpad.net/nova/+spec/service-version-behavior
在单个部署中，操作员可能有意或无意地运行多个版本的 nova 代码的情况有很多。我们可以通过代码做一些事情来使其更安全、更平滑，从而使操作员的生活更轻松。
问题描述¶
在运行多个版本的 Nova 代码时，必须小心避免发送对某些服务来说过于新（或过于旧）的 RPC 消息，以及避免使用无法处理潜在模式偏差的对象模型访问数据库。
目前，在升级期间，操作员必须计算并在相关的 RPC 接口上设置版本固定，以便较新的服务（conductor、api 等）可以与较旧的服务（compute）通信，而多种版本同时存在。这涉及很多步骤、配置调整和重启服务。错误执行或遗漏步骤的可能性很高。
此外，在正常操作期间，可能长时间离线的旧 compute 主机可能会被重启并尝试加入系统，此时兼容性代码（或配置）可能已被移除。
在这两种情况下，nova 应该能够帮助识别、避免和自动化复杂的任务，这些任务最终归结为基于报告的版本进行逻辑决策。
用例¶
作为操作员，我希望实时升级更容易，所需的步骤更少，nova 的行为更宽容。
作为操作员，我希望有更多的自动化检查，防止过时的 compute 节点在长时间休眠后尝试重新加入。
提议的变更¶
在 Liberty 中，我们添加了一个全局服务版本计数器。这会记录每个服务的版本信息到数据库中，并提供一些历史信息（例如，在每次全局版本更新时的 compute rpc 版本）。在 Mitaka 中，我们应该利用这一点来自动化一些任务。
我们将自动化的第一件事是 compute RPC 版本选择。目前，操作员在实时升级期间在配置文件中设置版本固定，并在升级完成后将其删除。我们将添加一个选项将其设置为“auto”，它将根据数据库中报告的服务版本选择 compute RPC 版本。通过查找最低服务版本，我们可以查阅 SERVICE_VERSION_HISTORY 结构来确定最旧的节点支持的 compute RPC 版本。我们可以通过在 compute_rpcapi 模块启动时和接收到 SIGHUP 等信号时在数据库中进行一次查找，使这对于其他代码透明。
只有在版本固定设置为“auto”时才会这样做，要求操作员选择加入这种新行为，同时进行测试。在自动选择版本的情况下，决策（以及它是最新版本还是降级版本）将被记录用于审计目的。
我们将自动化的第二个更改是在服务记录创建/更新期间检查最低服务版本。这将防止过时的服务加入部署，如果它们太旧。这将在 Service 对象中完成，它会将自己的版本与数据库中其他服务的最低版本进行比较。如果它比所有其他节点都旧，那么它将拒绝启动。如果拒绝启动，我们将记录涉及的版本和拒绝原因，以便清楚地了解发生了什么以及需要修复什么。
备选方案¶
我们可以继续记录这两个过程，并要求操作员执行手动步骤。
数据模型影响¶
这里的工作没有规定任何数据（库）模型影响，因为这些已经在 Liberty 中预先添加了。
Service 对象将获得至少一个可远程调用的方法，用于确定最低服务版本。
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
在 compute_rpcapi 模块启动时检查数据库中的最低版本会产生轻微的性能损失和额外的数据库负载。这只会发生一次（或在接收到信号时），预计比手动执行正在自动化的步骤所花费的精力要小得多。
Conductor 还可以缓存最低版本，以便在大量服务启动时避免访问数据库，这也很容易实现。
其他部署者影响¶
部署影响应该是完全积极的。其中一种行为最初是可选的，而另一种纯粹是为了防止操作员自食其果。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
danms
工作项¶
在 Service 对象中添加最低版本查询
在版本固定设置为 auto 时，自动化 compute RPC 版本的选择
在服务版本过旧时，自动化服务启动失败
将重新检查最低版本挂接到接收 SIGHUP 信号
依赖项¶
无
测试¶
与所有影响 nova 服务启动的内容一样，单元测试是测试服务在版本过旧时无法启动的唯一方法。
compute RPC 版本固定可以通过将 grenade 的 partial-ncpu 作业配置为使用“auto”而不是显式固定来测试。通过验证 tempest 在 nova 以这种方式配置时继续通过，可以验证选择了正确版本。
文档影响¶
每个更改都需要一些文档，仅仅是为了解释 compute_rpc 版本固定的新允许值以及启动旧服务的新潜在行为。
