TripleO - Ansible 升级工作流与 UI 集成

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/tripleo/+spec/major-upgrade-workflow

在 Pike 周期中，次要更新和部分主要升级与任何先前周期有显著不同，因为它们不是通过 Heat 堆栈更新传递到节点的。相反，Heat 堆栈更新仅用于收集，但不执行，每个服务 manifests 中定义的相应 ansible 任务，作为 upgrade_tasks 或 update_tasks。这些任务随后作为堆栈 outputs 中的独立 ansible playbook 编写。

这些“config”playbook 然后使用 openstack overcloud config download 实用程序 下载，并最终执行以交付实际的升级或更新。有关此机制在 P 周期中的使用情况的更多信息（或指针/审查），请参阅 bug 1715557 和 1708115。

对于 Queens，并且如丹佛 PTG 中讨论的那样，我们旨在将这种方法扩展到包括控制平面升级。也就是说，我们不应该使用 HEAT SoftwareConfig 和 Deployments 来 调用 ansible，而应该将控制平面节点的 upgrade_tasks 收集到 ansible playbook 中，然后调用这些 playbook 以交付实际的升级。

问题描述

虽然在每个周期中都在不断改进，但升级的复杂性和调试或理解在任何给定时间点执行了什么的难度仍然是运营商对 TripleO 升级工作流的主要抱怨。在 P 周期中，如上所述，次要版本更新和部分“非控制器”升级已经迁移到此处提出的模型，即生成 ansible-playbooks，并通过初始 Heat 堆栈更新执行它们。

如果我们对升级的所有部分（包括控制平面服务）都采用这种方法，那么我们还需要一个 mistral 工作簿来处理 ansible-playbook 调用下载和执行。通过这种由 mistral action/workbook 执行的 ansible 驱动的工作流，我们可以首次考虑与 UI 集成进行升级/更新。这与 UI 团队为 Queens 的 CLI/UI 功能对等性所做的 努力 一致。还应注意的是，已经有一些工作正在进行，以添加所需的 mistral actions，至少对于 Pike 部署的次要更新，请参见更改 487488 和 487496

为整个主要升级工作流实现完全由 ansible-playbook 交付的工作流将提供许多好处

  • 非常短的初始 Heat 堆栈更新以生成 playbook

  • 更容易跟踪和理解升级的给定步骤中发生的事情

  • 更容易调试和重新运行升级的任何特定步骤

  • 意味着对 ansible-playbook 调用具有完全的 python-tripleoclient 和 mistral 工作簿支持。

  • 可以考虑将升级/更新集成到 UI 中，这是第一次

提议的变更

我们需要一个初始 Heat 堆栈更新，以将 upgrade_tasks_playbook 填充到 overcloud 堆栈输出中（cli 只是一个建议）

升级的第一步将用于交付任何必需的通用升级初始化，例如切换到目标版本的仓库，安装升级期间所需的任何新软件包，以及填充升级 playbook。

然后操作员将运行针对特定节点的升级

  • openstack overcloud upgrade –nodes [overcloud-novacompute-0, overcloud-novacompute-1] 或 openstack overcloud upgrade –nodes “Compute”

下载并在特定指定的节点集上执行 ansible playbook。理想情况下，我们将使其能够指定一个角色名称，playbook 将以滚动方式在每个节点上调用。

所需更改之一是将所有服务模板转换为具有“when”条件而不是当前的“stepN”。对于 Pike，我们在 客户端 中执行此操作，以避免破坏仍然在 Ocata 到 Pike 升级期间为控制平面使用的 Heat 驱动的升级工作流。这将允许我们使用当前在生成的 ansible playbook 中使用的“ansible-native” 循环 控制。

其他最终用户影响

如上所述，操作员使用的主要升级工作流和 cli 将发生重大变化。

性能影响

初始 Heat 堆栈更新不会将任何 puppet 或 docker 配置传递到节点，因为 DeploymentSteps 将被 禁用，就像我们目前为 Pike 次要更新所做的那样。这将意味着更短的 Heat 堆栈更新 - 确切数字待定，但“分钟而不是小时”。

开发人员影响

应该使开发人员更容易调试升级工作流程的特定部分。

实现

负责人

贡献者：Marios Andreou (marios) Mathieu Bultel (matbu) Sofer Athlang Guyot (chem) Steve Hardy (shardy) Carlos Ccamacho (ccamacho) Jose Luis Franco Arza (jfrancoa) Marius Cornea (mcornea) Yurii Prokulevych (yprokule) Lukas Bezdicka (social) Raviv Bar-Tal (rbartal) Amit Ugol (amitu)

工作项

  • 删除步骤并为所有 ansible 升级任务、次要更新任务、部署步骤、post_upgrade_tasks 添加 when

  • 需要能够调用工作流所需阶段（–init 和 –nodes）的 mistral 工作簿。在 463765 中已经有一些现有的工作。

  • CLI/python-tripleoclient 更改所需。与前一个项目相关，在 463728 中已经开始进行一些工作。

  • UI 工作 - 我们需要与 UI 团队合作进行集成。我们从未有过由 UI 驱动的升级或更新。

  • CI：实现一个简单的作业（一个节点，仅控制器，执行 heat-setup-output 并运行 ansible –nodes Controller），使用 keystone 仅升级。然后，随着交付此规范所需的各种更改越来越接近合并，我们对其进行迭代。

  • 文档！

测试

我们将尽快发布一个“keystone-only”作业，该作业将随着交付此规范所需的各种更改越来越接近合并而更新。例如，我们可能会仅部署一小部分服务（例如，首先 keystone），然后随着与此规范相关的更改的提出进行迭代。

文档影响

我们还应该跟踪文档的升级工作流程中的更改，因为如本文所述，它将从内部以及暴露给操作员的接口方面发生重大变化。

参考资料

查看 来源 以获取链接