通过 Mistral 支持 TripleO Overcloud 部署¶

我们需要一个 TripleO 库来支持 overcloud 部署工作流。

问题描述¶

TripleO 具有一个 overcloud 部署工作流，该工作流使用 Heat 模板并包含以下步骤

用户编辑模板和环境文件。这些文件可以存储在任何地方。
Heat 可以验证模板。
模板和环境被发送到 Heat 以进行 overcloud 部署。

此工作流已经由 CLI 支持。

然而，从 GUI 的角度来看，虽然工作流很简单，但并不容易操作。以下是一些出现的问题

此工作流中的一些业务逻辑包含在 CLI 本身中，这使得其他 UI 难以使用。
如果 TripleO overcloud 部署工作流发生变化，CLI 和 GUI 方法很容易出现分歧——这是一种危险的情况。
CLI 方法允许开放式的灵活性（CLI 不关心模板来自哪里），这对 GUI 来说是有害的（GUI 用户不关心模板存储在哪里，但一致的方法对于防止 GUI 和 CLI 之间出现分歧是可取的）。

需要创建通用代码，以适应 CLI 的灵活性和 GUI 用户需求的易用性。

提议的变更¶

为了解决这个问题，我们建议创建一个与 Mistral 集成的部署，包含以下内容

将 overcloud 部署工作流中涉及的业务逻辑封装在 tripleo-common 库中，利用 Mistral actions 和 workflows。
提供一个简化的工作流，以隐藏 GUI 用户不需要的复杂性
更新 CLI 以在适当的情况下使用此代码，以防止与 GUI 产生分歧。

前三点值得进一步解释。首先，让我们概述提议的 GUI 工作流。

用户将 Heat 部署模板推送到 swift。
用户定义 Heat 模板 capabilities 给定的模板资源类型的数值，这些数值存储在 environment[1] 中。请注意，此规范将在 mitaka 中完成。下面讨论了一个解决方法。
现在已经指定了模板资源类型，用户可以配置 Heat 给定的部署参数。编辑后的参数被更新并存储在 environment 中。‘Roles’ 仍然可以从可用的 Heat 参数[2] 中派生。
可以重复步骤 2 和 3。
配置完成后，用户触发 overcloud 的部署。模板和环境文件从 Swift 中获取并发送到 Heat。
overcloud 部署完成后，执行任何需要的部署后配置。

CLI 和 GUI 都将使用 Swift 工作流并将模板存储到 Swift 中。这将促进从基于 CLI 的部署切换到 UI 以及反之亦然的可能性。

Mistral Workflows 由 Tasks 组成，Tasks 将一个或多个 Actions 分组在一起以供 Workflow Execution 执行。Action 实现为一个类，具有初始化方法和 run 方法。run 方法为 Python 代码提供单个执行点。Action 或 Workflows 需要的任何状态持久化都将存储在 Mistral Environment 对象中。

在某些情况下，OpenStack 服务可能缺少 TripleO 所需的功能，或者它可能只能通过其关联的 Python 客户端访问。为了短期内缓解此问题，某些 Actions 需要直接使用 Action Execution [3] 执行，Action Execution 直接调用 Action 并立即返回，但它也无法访问与 Workflow Execution 相同的上下文。从理论上讲，每个 action execution 都应该替换为 OpenStack 服务 API 调用。

以下是使用 python-mistralclient 或 Mistral API 从 CLI 或 GUI 执行的预期 Workflows 和 Actions 的摘要。可能需要额外的 actions 或库代码来启用这些操作，这些操作不打算直接使用。

工作流程

节点注册

节点内省

计划创建

计划删除

部署

验证操作

动作

计划列表

获取 Capabilities

更新 Capabilities

获取 Parameters

更新 Parameters

Roles 列表

对于 Flavors 和 Image 管理，将分别使用 Nova 和 Glance APIs。

节点的注册和内省将在 Mistral Workflow 中实现。逻辑当前在 tripleoclient 中，将被移植，因为某些节点配置被指定为逻辑的一部分（ramdisk、内核名称等），因此用户不必指定这些配置。标记、列出和删除节点将通过适当的 Ironic/Inspectors APIs 进行。

部署计划由 Swift 容器中的一组 heat 模板组成，以及存储在 Mistral Environment 中的数据。首次创建计划时，将解析 capabilities map 数据并存储在关联的 Mistral Environment 中。模板需要上传到与要创建的 stack 具有相同名称的 Swift 容器中。虽然任何用户都可以使用原始 POST 请求来完成此操作，但 GUI 和 CLI 将提供便利函数来改善用户体验。便利函数将在可以直接使用或包含在 Workflow 中的 Action 中实现。

计划的删除将在 Workflow 中实现，以确保在删除模板、容器和 Mistral Environment 之前没有关联的 stack。列出计划将通过调用 ‘mistral environment-list’ 来完成。

要获取可用 Heat 环境文件的列表及其描述和约束，该库将有一个 Action，该 Action 返回在计划创建期间添加的 capabilities 的信息，并标识哪些 Heat 环境文件已被选择。还会有一个 action 接受用户选择的 Heat 环境文件列表，并将信息存储在 Mistral Environment 中。使用 Workflow 执行这些操作将不方便，因为它们只是读取或更新 Mistral Environment，并且不需要额外的逻辑。

Roles 的识别将在调用 Heat 的 Workflow 中实现。

要获取部署参数，将创建 Actions，这些 Actions 将调用 Heat 并提供所需的模板信息以获取参数并将参数值设置为 Environment。

要执行 TripleO 验证，将创建 Workflows 和相关的 Actions 以支持 list、start、stop 和 results 操作。有关 Mistral 如何实现验证的更多信息，请参阅规范 [4]。

替代方案¶

一种替代方案是强制非 CLI UI 重新实现当前包含在 CLI 中的业务逻辑。这不是一个好的替代方案。另一种可能的替代方案是创建一个 REST API [5] 来抽象 TripleO 部署逻辑，但这需要付出更多的努力来创建和维护，并且已经在邮件列表中进行了广泛讨论。[6][7]

安全影响¶

其他最终用户影响¶

–templates 工作流最终将被修改为使用更新的 tripleo-common 库。

与 Mistral 集成是一个简单的过程，这可能会导致使用量增加。

性能影响¶

无

其他部署者影响¶

无

开发人员影响¶

现在，开发人员将不再直接在 python-tripleoclient 中编写 workflow 代码，而是创建 Mistral Actions 和 Workflows 来帮助实现需求。

目前，更改 overcloud 部署工作流会导致压力，因为需要单独更新 CLI 和 GUI 代码。将两者合并使这成为一个更容易实现的目标。但是，开发人员需要牢记这种架构，并确保对 –templates 或 –plan 工作流的更改在 tripleo-common 库中维护（在适当的时候），以避免不必要的差异。

实现¶

负责人¶

主要负责人

rbrady
jtomasek
dprince

工作项¶

所需的工作项是

开发 tripleo-common Mistral actions，提供我们部署工作流所需的所有功能。
这涉及将大部分代码从 python-tripleoclient 移到通用、狭窄的 Mistral actions 中，这些 actions 可以通过 Mistral API 消费。
创建新的 Mistral workflows 来帮助处理高级任务，例如部署、内省、节点注册等。
tripleo-common 更像是一个内部库，其逻辑旨在由使用 Mistral actions 消费（几乎）完全。项目不应尝试通过将 tripleo-common 作为库来绕过 API，尽可能多地。对于常见的轮询函数等，可能会有一些例外，但通常所有核心工作流逻辑都应由 API 驱动。
更新 CLI 以直接通过 python-mistralclient 消费这些 Mistral actions。

实现这些更改的所有补丁都必须通过 CI，并根据需要添加额外的测试。

依赖项¶

无

测试¶

应更新 TripleO CI 以测试更新的 tripleo-common 库。

我们的意图是让 tripleoclient 消费我们编写的 Mistral actions。由于所有现有的上游 Tripleo CI 在 tripleoclient 上发布，因此这种方法确保我们的所有工作流 actions 始终有效。这应该使我们覆盖 90% 的 Mistral actions 和 workflows，并允许我们以迭代/快速的方式进行实现。一旦 UI 安装并成为我们上游 CI 的一部分，我们也可以依靠那里的覆盖率来确保我们没有出现中断。

文档影响¶

Mistral Actions 和 Workflows 某种程度上是自文档化的，并且可以通过在命令行上运行 ‘mistral workflow-list’ 或 ‘mistral action-list’ 轻松地进行内省。但是，更新的库必须文档完善并符合 OpenStack 标准。需要在 tripleo-common 和 tripleo-docs 存储库中提供文档。