RpcMajorVersionUpdates

OpenStack 中 RPC API 主要版本的升级

OpenStack 组件（如 Nova）中服务之间暴露的 RPC API 都有版本号。通常，更改必须向后兼容，并伴随一个次要版本增加以反映该更改。我们偶尔会进行主要版本增加，以便能够删除提供向后兼容性的代码。这将在一个主要发布边界上完成。例如，在 Icehouse 发布之前添加了对新 API 版本的支持，并在 Juno 开发开始后删除旧版本的支持。

这些更改的细节分为两类。在大多数情况下，我们不允许暴露 RPC 接口的服务存在混合版本环境。在 Nova 中，我们允许混合版本环境的唯一情况是 compute 服务。我们支持 compute 服务的滚动升级。在这种情况下，更新的处理方式与其余部分略有不同。

非混合版本环境（大多数情况）

更新通过 2 个变更完成。

变更 #1

• 在主要发布之前合并。
• 为管理器（服务器）端添加对 rpc 主要版本 N+1 的支持。
• 更新 rpcapi（客户端）以发送 N+1 消息。
• 在管理器端保留对版本 N 的支持。
• 示例
  • https://review.openstack.org//79100
  • https://review.openstack.org/81008

管理器端同时支持 N 和 N+1 非常重要，这对于升级至关重要。以 nova-conductor 为例。它是一个非混合环境服务，因为我们期望所有正在运行的 nova-conductor 实例都是相同版本。但是，Nova 部署可能包含旧的 nova-compute 服务，这些服务尚未知道如何发送“N+1”消息。为了支持完整的部署，nova-conductor 必须保留*接收* N 和 N+1 消息的能力，直到整个部署完成升级为止。

变更 #2

• 在下一个主要发布开发开始后合并。
• 删除管理器端对版本 N 的支持。
• 使用“UpgradeImpact”标记提交。请注意，部署*必须*已经升级到包含变更 #1。
• 示例
  • https://review.openstack.org/#/c/54493/

混合版本环境（nova-compute）

此情况与非混合版本环境中的操作非常相似。遵循该过程，但有以下例外：

• 在变更 #1 中，必须保留 rpcapi（客户端）端支持，以使用旧 rpcapi 版本 (N) 发送消息。
• 示例
  • https://review.openstack.org/#/c/53944/

部署需要能够将客户端版本固定到旧版本，直到升级完成。升级完成后，可以删除客户端版本固定，并且客户端可以开始发送新消息 (N+1)。考虑 nova-compute 服务。在执行 nova-compute 的滚动升级时，我们必须发送所有服务都理解的消息版本。一旦它们全部升级，就可以发送新消息了。