TripleO Overcloud 部署的库支持

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

问题描述

由于 Tuskar 不足以处理复杂的 overcloud 部署，TripleO 已经转向一个绕过 Tuskar 的 overcloud 部署工作流。该工作流可以总结如下：

• 用户编辑模板和环境文件。这些文件可以存储在任何地方。

• 模板可以被 Heat 验证。

• 模板和环境被发送到 Heat 进行 overcloud 部署。

• 部署后，配置 overcloud 端点。

这个工作流已经被 CLI 支持。

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

• 此工作流中的一些业务逻辑包含在 CLI 本身中，这使得其他 UI 难以使用。

• 如果 TripleO overcloud 部署工作流发生变化，CLI 和 GUI 方法很容易出现分歧——这是一种危险的情况。

• CLI 方法允许开放式的灵活性（CLI 不关心模板来自哪里），这对 GUI 来说是有害的（GUI 用户不关心模板存储在哪里，但一致的方法对于防止 GUI 之间的分歧是可取的）。

需要创建通用代码，以适应 CLI 的灵活性和基于 Python 的 GUI 消费者的易用性需求。请注意，最终需要一个 API 来适应非 Python GUI。相关工作将在单独的规范中详细说明。

提议的变更

为了解决这个问题，我们提出以下建议：

• 将 overcloud 部署工作流中涉及的业务逻辑封装在 tripleo-common 库中。

• 提供一个简化的工作流，以隐藏 GUI 消费者不需要的复杂性——例如，模板存储。

• 更新 CLI 以在适当的地方使用此代码，以防止与 GUI 产生分歧。

前两点值得进一步解释。首先，让我们阐述建议的 GUI 工作流。我们将用户希望用于 overcloud 部署的 Heat 文件称为“计划”。

1. 用户通过将 Heat 部署模板的副本推送到数据存储中来创建计划。

2. 用户定义 Heat 模板功能给出的模板资源类型的值。这导致环境文件中的资源注册表更新并保存到数据存储中。（https://review.openstack.org/#/c/196656/7/specs/liberty/resource-capabilities.rst）请注意，此规范将在 mitaka 时最早完成。下面讨论了一个解决方法。

3. 现在模板资源类型已指定，用户可以配置 Heat 给出的部署参数。编辑后的参数已更新，并且更新后的环境文件已保存到数据存储中。“角色”不再存在于 Tuskar 中，但仍然可以从可用的 Heat 参数中推断出来。（https://review.openstack.org/#/c/197199/5/specs/liberty/nested-validation.rst）

4. 可以重复步骤 2 和 3。

5. 配置完成后，用户触发 overcloud 的部署。模板和环境文件从数据存储中获取并发送到 Heat。

6. overcloud 部署完成后，执行任何需要的部署后配置。

为了实现此工作流，我们建议最初推广使用 Swift 作为模板数据存储。这种用法将被 tripleo-common 库抽象化，后续更新可能会允许使用其他数据存储。

请注意，Swift 工作流旨在作为当前 CLI “--templates” 工作流的替代方案。两者最终都将成为 CLI 下的选项；用户可以选择“--templates”或“--plan”。但是，它们都将由通用的 tripleo-common 库代码支持，而“--plan”选项只是调用其他函数从 Swift 中提取计划信息。如果 GUI 期望基于 Swift 的部署，则使用“--templates”CLI 工作流部署时将失去功能。

tripleo-common 库所需的功能是：

• 计划 CRUD

  • create_plan(plan_name, plan_files)：通过创建与 plan_name 匹配的 Swift 容器，并将所有用于该计划的文件（对于 Heat，将是“父”模板、嵌套堆栈模板、环境文件等）放入该容器中来创建计划。Swift 容器将创建对象版本控制处于活动状态，以允许版本更新。

  • get_plan(plan_name)：从与 plan_name 匹配的 Swift 容器中检索 Heat 模板和环境文件。

  • update_plan(plan_name, plan_files)：通过更新与 plan_name 匹配的 Swift 容器中的计划文件来更新计划。这可能需要更新环境文件以添加和/或删除参数。虽然更新是版本化的，但未来不会实现检索过去版本的功能。

  • delete_plan(plan_name)：如果不存在使用该计划部署的已部署 overcloud，则通过删除与 plan_name 匹配的 Swift 容器来删除计划。

• 部署选项

  • get_deployment_plan_resource_types(plan_name)：通过从 Swift 检索 plan_name 的模板并使用建议的 Heat resource-capabilities API（https://review.openstack.org/#/c/196656/7/specs/liberty/resource-capabilities.rst）来确定可用的模板资源类型。如果该 API 在所需的时间范围内未准备好，我们将实施一个临时解决方法——模板和提供程序资源之间的手动映射。我们将与规范开发者密切合作，以确保此方法输出与他们建议的输出匹配，以便在他们的 API 准备好后可以轻松替换。

  • update_deployment_plan_resource_types(plan_name, resource_types)：从 Swift 检索 plan_name 的环境文件，并根据 resource_types 传递的值更新资源注册表树。然后更新 Swift 中的环境文件。

• 部署配置

  • get_deployment_parameters(plan_name)：通过从 Swift 检索 plan_name 的模板并使用建议的 Heat nested-validation API 调用（https://review.openstack.org/#/c/197199/5/specs/liberty/nested-validation.rst）来确定可用的部署参数。

  • update_deployment_parameters(plan_name, deployment_parameters)：从 Swift 检索 plan_name 的环境文件，并根据 deployment_parameters 传递的值更新参数。然后更新 Swift 中的环境文件。

  • get_deployment_roles(plan_name)：确定可用的部署角色。可以通过检索 plan_name 的部署参数并从参数名称推断可用的角色来完成；或者通过查看顶层 ResourceGroup 类型。

• Deployment

  • validate_plan(plan_name)：从 Swift 检索 plan_name 的模板和环境文件，并在 Heat API 验证调用中使用它们。

  • deploy_plan(plan_name)：从 Swift 检索 plan_name 的模板和环境文件，并在 Heat API 调用中使用它们来创建 overcloud 堆栈。执行模板的任何需要的预处理，例如 Heat 所需的模板文件字典。此函数将返回一个 Heat 堆栈 ID，可用于监视部署状态。

• 部署后

  • postdeploy_plan(plan_name)：初始化与 plan_name 对应的 overcloud 的 API 端点。

替代方案

另一种选择是强制非 CLI UI 重新实现当前包含在 CLI 中的业务逻辑。这不是一个好的选择。

安全影响

其他最终用户影响

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

基于 Python 的代码将更容易适应 TripleO 的部署方法。这可能会导致使用量增加。

性能影响

无

其他部署者影响

无

开发人员影响

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

另一个需要注意的重要事项是，我们需要使 TripleO CI 与更改保持同步，并负责根据需要修复 CI。

实现

负责人

主要负责人

• tzumainn

• akrivoka

• jtomasek

• dmatthews

工作项

所需的工作项是

• 开发 tripleo-common 库以提供上述功能。这还涉及将代码从 CLI 移动到 tripleo-common。

• 更新 CLI 以使用 tripleo-common 库。

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

依赖项

我们依赖于两个 HEAT 规范

• Heat resource-capabilities API（https://review.openstack.org/#/c/196656/7/specs/liberty/resource-capabilities.rst）

• Heat nested-validation API（https://review.openstack.org/#/c/197199/5/specs/liberty/nested-validation.rst）

测试

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

文档影响

更新的库及其 Swift 支持的工作流必须经过充分记录，并符合 OpenStack 标准。需要在 tripleo-common 和 tripleo-docs 存储库中提供文档。

参考资料