改进升级任务 CI 覆盖率，使用独立安装程序

https://blueprints.launchpad.net/tripleo/+spec/upgrades-ci-standalone

这项工作的主要目标是通过利用 Standalone_installer_work，改进 tripleo ci 升级作业中 service upgrade_tasks 的覆盖率。使用独立节点作为单个节点“overcloud”使我们能够在相同的作业和当前资源（2 个节点和 3 小时）内同时执行 controlplane 和 dataplane 服务。此外，一旦证明成功，这种方法可以扩展到包括单个服务升级测试，从而大大提高对 tripleo-heat-templates 中定义的所有 service upgrade_tasks 的当前覆盖率（目前覆盖率很低）。

传统上，升级作业受到资源限制（节点和运行时间）的限制。例如，undercloud 和 overcloud 升级从未在同一个作业中进行，即 overcloud 升级作业使用已经处于目标版本的 undercloud（所谓的混合版本部署）。

另一个例子是，升级作业通常执行 controlplane 或 dataplane 升级（即仅控制器，或仅计算），而从未在同一个作业中同时执行两者，同样是因为限制。当前正在运行的 tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades 作业例如，有 2 个节点，一个 undercloud，一个 overcloud 控制器。工作流程正在被执行，但仅控制器。此外，虽然 current_upgrade_ci_scenario 仅执行 controlplane 服务的一个小子集，但仍然运行超过 140 分钟。因此，在 tripleo-heat-templates 中定义的许多不同服务模板中，对 upgrades_tasks 的覆盖率也很低。

因此，这项工作的主要目标是使用独立安装程序来定义 ci 作业，以测试具有 controlplane 和 dataplane 服务的单节点“overcloud”的 service upgrade_tasks。这种方法是可组合的，因为独立节点中的服务是完全可配置的。因此，在 compute/control 的第一次迭代之后，我们还可以定义每个服务的 ci 作业，并随着时间的推移，希望达到对 TripleO 可部署的所有服务的覆盖率。

最后，值得强调的是，作为这项工作定义的工作不会测试 TripleO 升级工作流程。而是关于专门测试 service upgrades_tasks。工作流程将使用现有的 ci 升级作业进行测试（tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades），并进行修改以将其简化到所需的最低限度（例如，几乎没有服务）。在 TripleO-Stein-PTG 的讨论中还有更多指针，但最终我们将对 ci 中测试的升级进行两种近似 - 本规范描述的 service upgrade_tasks，以及使用不同 ci 作业或修改现有作业的工作流程本身。

问题描述

如上所述，我们无法在同一个 tripleo ci 作业中升级 control 和 dataplane 服务。这样的作业至少需要 3 个节点（undercloud、controller、compute）。

一个完整的升级工作流程需要以下步骤

• 部署 undercloud，部署 overcloud

• 升级 undercloud

• 升级准备 overcloud（heat stack update 生成 playbook）

• 升级运行控制器（ansible-playbook 通过 mistral 工作流程）

• 升级运行计算/存储等（重复直到全部完成）

• 升级收敛（heat stack update）。

这里要解决的问题是，我们只能运行升级工作流程的一些近似值，特别是 upgrade_tasks，用于一组组合的服务，并在 ci 超时时间内完成。第一次迭代将侧重于模拟一个具有 controller 和 compute 服务的单节点“overcloud”。如果证明这是成功的，我们还可以考虑为每个我们想要测试升级任务的服务定义单个服务升级作业。因此，即使这只是升级的一个近似值（仅 upgrade_tasks，而不是完整的流程），它也可以希望比目前可能实现的更广泛地覆盖 ci 中的服务。

在编写本规范时的一个早期考虑是，我们如何强制服务分离，相对于升级工作流程。也就是说，强制执行 controlplane upgrade_tasks 和 deploy_steps 首先执行，然后是 dataplane compute/storage/ceph，这通常是升级工作流程的情况。但是，对本规范的评论以及 PTG 周围的讨论，特别是这只是升级的一个近似值（service upgrade tasks，而不是工作流程），在这种情况下，在这里人为地诱导这种 control/dataplane 分离可能是不必要的。这可能需要在开始实施后重新审视。

另一个需要解决的核心挑战是如何从 tripleo-heat-templates 中收集 ansible playbook，因为我们没有传统的 undercloud heat stack 来查询。希望这不会是一个更大的挑战，假设我们可以重用用于部署独立节点的临时 heat 流程。此外，在 TripleO-Stein-PTG 的讨论告知我们一种在部署后使用 keep-running 保留 heat stack 的方法，因此我们可以像使用“正常”部署一样重新使用它。

提议的变更

概述

我们需要在 tripleo-ci_zuul.d_standalone-jobs 中定义一个新的 ci 作业（最好遵循当前正在进行中的 ci_v3_migrations 将其定义为 v3 作业）。

对于 playbook 本身的生成，我们希望使用用于部署独立节点的临时 heat 服务，或者使用 keep-running 选项来在部署后保留堆栈。

如问题陈述中所述，我们希望避免区分 control 和 dataplane 服务以强制 controlplane 服务首先升级的任务。

替代方案

添加另一个节点并拥有 3 个节点升级作业以及增加运行时间，但这从长远来看是不可扩展的，假设资源有限！

安全影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

更多的服务覆盖意味着更少的破坏，因为升级不兼容的东西被合并。

开发人员影响

对于可能无法访问资源的开发人员来说，也可能更容易，他们可以使用带有独立作业的 reproducer 脚本并获得一个用于测试升级的开发环境。

实现

负责人

tripleo-ci 和升级小队

工作项

首先，我们必须解决生成独立升级任务的 playbook 的问题，包括 tripleo-heat-templates 在升级时（包括所有 upgrade_tasks 等）的所有最新配置，而没有 undercloud Heat stack 可以查询。

我们可能会考虑一些非 heat 解决方案，通过解析 tripleo-heat-templates，但我认为这不是一个可行的解决方案（重新发明轮子）。目前正在进行的工作是将任务转移到角色，这很有希望，这是另一个可以探索的领域。

鉴于当前工具，一个明显的机制是重用独立节点在部署 overcloud 时使用的相同的临时 heat 流程，但设置用于简短堆栈“更新”的通常的“upgrade-init”环境文件。这尚未经过测试，因此需要进一步调查。如前所述，现在实际上有一个 keep-running 选项到 tripleoclient，它将使这个 heat 流程保持活动状态

对于这项工作的第一次迭代，我们将旨在利用最小的可能服务组合来实现“compute”/“control”overcloud。也就是说，使用现有服务来自 current_upgrade_ci_scenario，并添加 nova-compute 及其依赖项。

最后，第三个主要考虑因素是如何执行此服务升级，即如何调用 playbook 生成然后运行生成的 playbook（如果只对升级任务感兴趣，可能不需要收敛）。一个考虑因素可能是重用现有的 python-tripleoclient “openstack overcloud upgrade” prepare 和 run 子命令。但是，第一种也是目前首选的方法是使用现有的独立客户端命令（tripleo_upgrade tripleo_deploy）。因此，一项工作是尝试这些并发现我们需要对其进行任何修改才能使其为我们工作。

项目

• 找出/确认生成独立升级任务的 playbook。

• 找出执行 ansible playbook所需的客户端/工具中的任何更改

• 在 tripleo-ci_zuul.d_standalone-jobs 中定义新的 ci 作业，其中包含 control 和 compute 服务，将执行 upgrade_tasks、deployment_tasks 和 post_upgrade_tasks playbook。

一旦完成第一次迭代，我们就可以考虑为小型服务子集或甚至单个服务定义多个作业。

依赖项

这显然取决于独立安装程序

测试

这里至少会定义一个新作业

文档影响

无

参考资料