升级检查

注意

本文档详细介绍了如何在新的功能或错误修复中生成升级检查。有关如何应用现有的升级检查的信息，请参阅 nova-status 命令的文档，位于 nova-status。有关 nova 部署的通用升级过程的信息，请参阅 升级。

Nova 提供了自动化的 升级检查工具，以帮助部署工具验证部署的关键部分，尤其是在升级期间需要操作员干预的重大更改时。

本指南涵盖了 nova 升级检查工具的背景、如何使用它以及编写新检查时需要注意的事项。

背景

Nova 历史上支持离线数据库模式迁移（nova-manage db sync 和 nova-manage api_db sync）和在线数据迁移（nova-manage db online_data_migrations）在升级期间，如 数据库迁移 中所述。在 15.0.0 (Ocata) 版本中引入了 nova-status upgrade check 命令，以帮助验证该版本中的两个主要必需更改，即 Placement 和 Cells v2。

从 14.0.0 Newton 版本开始，与 Placement 服务的集成和部署 Cells v2 是可选的，并在 Ocata 版本中变为必需。致力于这些更改的 nova 团队知道，为了成功升级到 Ocata，需要进行必需的部署更改。此外，必需的部署更改不能简单地通过数据库迁移脚本进行验证，例如，迁移脚本不应该向 Placement 发出 REST API 调用。

因此，nova-status upgrade check 被编写出来，以提供自动化的“飞行前”检查，以验证在升级到 Ocata 之前是否执行了必需的部署步骤。

请参阅 Ocata 更改 以获取实现细节。

指南

• 检查应该能够在虚拟环境或容器内运行。所需的一切都是一个完整的配置文件，类似于运行其他 nova-manage 类型的管理命令。在 nova 的情况下，这意味着需要配置 api_database、placement 等部分。

• 自动化升级检查的候选对象是项目升级发布说明中的可以通过数据库验证的内容。例如，在升级到 Ocata 的 Cells v2 时，一个必需的步骤是为 cell0 和 cell1 创建“单元映射”。可以通过检查 nova_api 数据库中的 cell_mappings 表的内容来轻松验证这一点。

• 检查将查询数据库（取决于检查）和潜在的 REST API，但不应期望运行 RPC 调用。例如，检查不应该要求 nova-compute 服务在特定主机上运行。

• 检查通常旨在在重新启动和升级到新服务代码之前运行，就像 grenade 使用它们 一样，但它们也可以作为 安装后验证步骤 运行，就像 openstack-ansible 也使用它们一样。在 grenade 中升级 nova 的高级步骤集是

  • 安装新代码

  • 同步新模型的数据库模式 (nova-manage api_db sync; nova-manage db sync)

  • 运行在线数据迁移 (nova-manage db online_data_migrations)

  • 运行升级检查 (nova-status upgrade check)

  • 使用新代码重新启动服务

• 检查必须是幂等的，以便可以重复运行它们，并且结果始终基于最新数据。这允许操作员运行检查，修复报告的任何问题，然后迭代直到状态检查不再报告任何问题。

• 不能轻松或不应该在离线数据库迁移中运行的检查是这些 CLI 驱动检查的良好候选对象。例如，instances 记录位于单元数据库中，对于每个实例，应该在 nova_api 数据库中有一个相应的 request_specs 表条目。在 Newton 版本中添加了一个 nova-manage db online_data_migrations 例程来回填现有实例的请求规范，并且在 Rocky 中添加了一个升级检查，以确保所有未删除的实例都具有请求规范，以便在 Stein 中可以删除兼容性代码。在 nova 的早期版本中，我们将添加一个 阻止迁移 作为数据库模式迁移的一部分，以确保在升级可以继续之前已完成在线数据迁移。

  注意

  使用 nova-status upgrade check 不排除给定数据库中需要阻止迁移，但在请求规范的情况下，检查跨多个数据库并且更适合 nova-status 工具。

• 所有检查都应该有一个配套的升级发布说明。

结构

检查没有图形逻辑，这意味着每个检查都旨在独立于同一集合中的其他检查运行。例如，一个项目可以有五个串行运行的检查，但这并不意味着集合中的第二个检查依赖于集合中第一个检查的结果，或者第三个检查依赖于第二个检查，依此类推。

基本框架非常简单，如 初始更改 所示。每个检查都注册在 _upgrade_checks 变量中，并且 check 方法执行每个检查并记录结果。记录最严重的结果作为最终返回代码。

每个检查有三种可能的结果

• Success：所有升级准备检查都已成功通过，无需执行任何操作。

• Warning：至少有一个检查遇到问题，需要进一步调查。这被认为是一个警告，但升级可能是可以的。

• Failure：有一个升级状态检查失败，需要调查。这应该被认为是阻止升级的事情。

UpgradeCheckResult 对象提供了在有警告或失败结果时添加详细信息，通常应该引用如何解决失败，例如，可能 nova-manage db online_data_migrations 不完整并且需要再次运行。

以 cells v2 检查 为例，实际上涉及两个检查

1. cell0 和 cell1 映射是否存在？

2. 如果单元数据库中有计算节点记录，API 数据库中是否存在主机映射？

任何一个检查失败都会导致该检查的 Failure 状态以及整体运行的 2 返回代码。

初始 placement 检查 提供了一个警告响应的示例。在该检查中，如果在 Placement 中资源提供商少于单元数据库中的计算节点，部署可能利用率不足，因为 nova-scheduler 正在使用 Placement 服务来确定调度候选主机。

警告结果适用于已知可以通过滚动升级过程运行的情况，例如，nova-compute 被配置为将资源提供商信息报告到 Placement 服务。这些事情应该在某个时候进行调查和完成，但可能不会导致任何立即失败。

结果馈送到检查的标准输出

$ nova-status upgrade check
+----------------------------------------------------+
| Upgrade Check Results                              |
+----------------------------------------------------+
| Check: Cells v2                                    |
| Result: Success                                    |
| Details: None                                      |
+----------------------------------------------------+
| Check: Placement API                               |
| Result: Failure                                    |
| Details: There is no placement-api endpoint in the |
|          service catalog.                          |
+----------------------------------------------------+

常见问题解答

• 如何打包和部署 nova-status 升级脚本？

  在 setup.cfg 文件中为 nova-status 有一个 console_scripts 条目。

• 为什么命令结构有多个部分，即“upgrade”和“check”？

  这是 nova-manage 命令的结构，具有子命令类别，例如 nova-manage db 是由其他子命令（如 nova-manage db sync）组成的子类别。为了保持一致性和可扩展性，如果以后需要添加其他子命令，nova-status upgrade check 命令以相同的方式编写。

• 为什么升级检查命令不属于标准的 python-*client CLI？

  nova-status 命令是根据 nova-manage 命令建模的，该命令旨在仅供管理员使用，并可以直接访问数据库，而其他 CLI 包（如 python-novaclient）需要一个令牌并通过 REST API 与 nova 通信。因此，也可以编写在 nova-manage 和 nova-status 中可以工作，即使 API 服务正在维护的命令。

• 应该如何记录检查？

  每个检查都应该记录在 CLI 指南的 历史记录部分 中，并有一个发布说明。这很重要，因为检查可以在与实际部署的代码隔离的环境中运行，并且由于检查应该是幂等的，因此历史记录/更改日志对于了解正在验证的内容很有用。

• 其他项目是否支持升级检查？

  Stein 版本的一个社区范围内的 目标 是将相同类型的 $PROJECT-status upgrade check 工具添加到其他项目，以便简化整个 OpenStack 的升级。因此，虽然本文档中的指南主要针对 nova，但它们也应普遍适用于希望合并相同工具的其他项目。

• 其他项目文档应该放在哪里？

  作为标准 OpenStack 项目 文档指南 的一部分，该命令应该记录在每个项目仓库的 doc/source/cli 下。

• 可以追溯升级检查吗？

  有时可以追溯升级检查，以帮助预防稳定分支上的错误。例如，为 bug 1759316 添加了一个 Rocky 检查，该检查也追溯到 stable/queens，以防任何人从 Pike 升级到 Queens 时遇到相同的问题。可追溯的检查通常仅针对潜在的错误，因为已经通过检查并升级到给定稳定分支的人不应该在同一分支上的补丁发布后开始失败。因此，任何追溯的检查都应该附带一个发布说明。

• 升级检查只能用于 N-1 到 N 版本的升级吗？

  不一定。升级检查也是快速升级的重要组成部分，以确保在滚动每个版本执行模式（数据模型）更新和数据迁移时，您也完成了所有必要的更改。例如，如果您从 Ocata 快速升级到 Rocky，Pike 或 Queens 中可能添加、弃用或删除了某些内容，而升级前检查是一种确保在重新启动 Rocky 代码之前，在升级这些版本时采取了必要步骤的方式。