在 python-tripleoclient 中提供一个通用的验证框架¶
https://blueprints.launchpad.net/tripleo/+spec/validation-framework
目前，tripleoclient 缺乏一个通用的验证框架。该框架应提供一种简便的方法，以便在部署之前以及在 undercloud 和 overcloud 上更新/升级之前验证环境。
问题描述¶
目前，我们有两种类型的验证
在 undercloud 部署之前启动的，嵌入到部署本身中的验证
通过 Mistral Workflow 随时启动的验证
没有一种统一的方式可以轻松地单独调用任何验证，并且我们缺乏轻松为 undercloud 预检添加新验证的能力。
当前情况并非最佳，因为操作员必须进入 UI 才能运行验证 - 存在一种通过与 UI 相同的 workflow 从 CLI 运行它们的方法。这不能用于获得适当的预检验证，尤其是在我们无法获得可用的 Mistral（在 undercloud 部署之前，或使用 all-on-one/standalone 时）的情况下。
此外，需要使 CLI 和 UI 融合。后者已经使用了完整的验证列表。将对 tripleo-validations 的完全支持添加到 CLI 将提高验证的整体质量、可用性和可维护性。
最后，应添加第三种类型：在部署本身期间调用的服务验证。这不会直接影响 tripleoclient 代码库，但会影响 tripleo-heat-templates。
提议的变更¶
概述¶
为了改进当前状况，我们建议在 tripleoclient 命令中创建一个新的“分支”：openstack tripleo validator
这个新的子命令将允许以独立的方式列出和运行验证。
这样做将允许我们清晰简洁地了解在当前阶段可以运行的验证。
(注意：子命令尚未定义 - 这只是一个“模拟”。)
应支持以下子命令
openstack tripleo validator list：将显示所有可用验证及其简短描述，例如“验证 undercloud 上的网络功能”openstack tripleo validator run：将运行验证。应接受选项，例如--validation-name：仅运行传递的验证。--undercloud：运行所有与 undercloud 相关的验证--overcloud：运行所有与 overcloud 相关的验证--use-mistral：通过 Mistral 运行验证--use-ansible：通过 Ansible 直接运行验证--plan：允许针对特定计划运行验证。默认值为 $TRIPLEO_PLAN_NAME 或“overcloud”
此外，所有子命令的通用选项
--extra-roles：指向包含操作员维护的验证角色的本地目录，或包含额外验证角色的 swift 目录。--output：指向有效的 Ansible output_callback，例如原生 json，或自定义 validation_output。默认值应为后者，因为它呈现“人类可读”的输出。以后可以添加更多回调。
--extra-roles 必须支持本地路径和远程 swift 容器，因为自定义验证支持会将任何验证推送到专用的 swift 目录。
默认引擎将由 Mistral 的存在决定：如果 Mistral 存在并接受请求（意味着 Undercloud 很可能已部署），则验证器必须默认使用它。如果没有 Mistral，它必须回退到 ansible-playbook。
验证应采用 Ansible 角色的形式，以便能够轻松地从 Mistral 访问（如当前情况）。它还将允许获得适当的文档、画布，并提供验证角色运行前的可能性（确保存在元数据、输出等）。
我们还可以创建一些专用的角色，以便进行一种“自我验证”，确保我们实际上可以运行验证（网络、资源等）。
UI 使用 Mistral workflow 运行验证 - CLI 必须能够使用相同的 workflow，但也要至少通过 ansible 直接运行一些验证，尤其是在我们想要在部署之前验证 undercloud 环境时。
此外，为了避免修改 Mistral，将创建包含验证角色的 playbook。
最终，所有默认验证角色都应位于一个且唯一的地点：tripleo-validations。在添加“自定义验证”的支持时，也应支持这些自定义验证（有关详细信息，请参阅参考资料）。
为了获得“瞄准”验证的正确方法，必须创建和记录适当的验证组。当然，一个验证可以属于多个组。
此外，应创建带有示例的适当文档，描述有关角色内容、格式和输出的最佳实践。
例如，一个角色应包含描述、一种“人类可读的错误输出”，以及如果适用，可能的解决方案。
可以添加对默认验证（即 tripleo-validations 中的验证）的适当测试，以确保新的验证遵循最佳实践。
我们可能希望添加对“与 nagios 兼容的输出”和退出代码的支持，但通过任何监控工具运行这些验证是否是一个好主意尚不确定，因为这可能会产生可能的负载。这需要在我们建立框架后进一步讨论。
替代方案¶
实际上没有真正的替代方案。目前，我们有很多验证方法，但它们都无关紧接，没有协调。如果我们不提供一个统一的框架，我们将获得越来越多的“侧面验证方式”，并且它将无法维护。
安全影响¶
某些验证可能需要权限 - 它们应相应地添加到系统 sudoers 中，以限制不必要的权限提升。
其他最终用户影响¶
最终用户将获得一种在采取任何操作之前验证环境的适当方法。这将增强对最终产品的信心，并简化更新和升级过程。
它还将提供一种收集有关系统故障信息的良好方法。
如果创建“与 nagios 兼容的输出”（ansible JSON 输出、解析和兼容性内容的混合），它可能会提供一种获取堆栈健康状况每日报告的方法 - 这可能是一个不错的特性，但不在当前范围内（需要一个新的 stdout_callback 例如）。
性能影响¶
我们获得的验证越多，如果我们决定在采取任何操作之前默认运行它们，则可能需要的时间就越多。
通过配置文件或 CLI 选项禁用它们的方式将保持不变。
此外，我们可以很好地利用“组”来过滤掉贪婪的验证。
其他部署者影响¶
为验证提供 CLI 子命令将使部署更容易。
提供统一的框架将允许操作员从 UI 或 CLI 运行验证，而无需对验证列表感到惊讶。
开发人员影响¶
需要在 python-tripleoclient 和可能在 tripleo-common 中进行重构，以获得适当的子命令和选项。
需要决定从 Python 调用 Ansible 的正确方法（ansible-runner？）。
如果它不存在，则需要创建一种从 CLI 调用 Mistral workflow 的正确方法。
最终，该框架将允许其他 Openstack 项目推送他们自己的验证，因为他们是知道如何在不同的服务中验证 Openstack 的人。
所有验证都将集中在 tripleo-validations 存储库中。这意味着我们可能希望创建适当的树，以避免在同一个目录中拥有 100 多个验证。
实现¶
负责人¶
- 主要负责人
cjeanner
- 其他贡献者
akrivoka ccamacho dpeacock florianf
工作项¶
列出 undercloud_preflight.py 和 openstack-tripleo-validations 中当前存在的验证。
决定是否将 ansible-runner 集成为依赖项（需要打包）。
将 undercloud_preflight 验证实现为 Ansible 角色。
实现从 tripleoclient 代码调用 Ansible 的正确方法。
实现用于验证的专用配置文件支持。
在 tripleoclient 中实现新的子命令树。
验证，验证，验证。
依赖项¶
Ansible-runner: https://github.com/ansible/ansible-runner
Openstack-tripleo-validations: https://github.com/openstack/tripleo-validations
测试¶
CI 无法提供具有所有要求的“正确”环境。代码必须实现一种配置验证的方法，以便 CI 可以覆盖我们将设置在验证中的“生产”值。
文档影响¶
必须在文档中创建一个新的条目，以描述这个新的框架（针对开发人员）和新的子命令（针对操作员）。
