Overcloud 飞行验证

https://blueprints.launchpad.net/tripleo/+spec/inflight-validations

目前，我们没有在部署过程中运行验证的方法。本规范旨在提供有关如何在 Overcloud 部署中实现此类飞行验证的必要信息。

问题描述

目前，操作员和开发人员必须等待很长时间才能在服务未按预期运行的情况下获得错误信息。

这会导致时间和资源的浪费。

提议的变更

概述

在每个容器/服务启动后，都会添加一个新的步骤，以便在已部署的主机上运行一个或多个验证，以确保该服务在该步骤中实际按预期工作。

这些验证不得使用 Mistral Workflow，以便为 undercloud/standalone 场景提供支持。

推送这些验证的最佳方法是通过现有的 deploy_steps_tasks 关键字。验证应该在下一个步骤的开始处，或者在我们想要检查的当前步骤的结束处。

验证应该指向外部 playbook，例如托管在 tripleo-validations 中。如果为验证创建 playbook 实际上没有用处，则可以内联 - 但必须简短，例如单个端口开放测试。

替代方案

实际上没有其他替代方案。我们可能会认为直接运行验证 ansible playbook 是一个好主意，但它会破坏与 UI 的期望收敛性。

目前，没有这样的验证，我们可以从头开始。

安全影响

没有安全影响。

升级影响

如果服务未正确启动，升级可能会失败。对于全新部署也是如此。

如果我们处于升级状态，我们可能需要不同的验证任务/工作流程。

其他最终用户影响

最终用户将在验证检测到问题时尽早失败。这是一项改进，因为目前它可能会在后续步骤中失败，并且由于缺少有效状态而破坏某些东西。

性能影响

运行飞行验证将会减慢整体部署/升级过程，但另一方面，它将确保我们在每个步骤之前都拥有一个干净的状态。

其他部署者影响

对其他部署器没有影响。

开发人员影响

需要创建和记录验证才能获得正确的运行。

实现

负责人

谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？

如果有多个人正在进行实现，请指定主要作者和联系人。

主要负责人

cjeanner

其他贡献者

<launchpad-id 或 None>

工作项

  • 为 validation_tasks 添加新的钩子

  • 提供关于其使用的适当文档

依赖项

测试

待定

文档影响

对文档有什么影响？不要重复上述讨论的细节，但请在此处引用它们。

参考资料