支持自定义 TripleO 验证¶
https://blueprints.launchpad.net/tripleo/+spec/custom-validations
目前所有验证都存储在单个目录中。这使得编写新的验证、从远程仓库更新或添加全新的（也许是私有的）源变得不方便。
问题描述¶
部署者希望在个人检出中开发和测试自己的验证，而不会冒着更改默认验证的风险。
部署者希望使用 TripleO 的稳定版本，但消费最新的验证，因为它们不会造成破坏性影响，并且会检查更多内容。
第三方开发了特定于其产品的验证，他们不想或不能将其包含在 tripleo-validations 仓库中。
提议的变更¶
概述¶
我们将把默认的 TripleO 验证存储在名为 tripleo-validations 的 Swift 容器中。这些将在所有计划之间共享，并且部署者预计不会更新它们。这个容器应该在初始 Undercloud 部署时创建。
我们将提供一种机制，允许部署者为每个部署计划添加一组自定义验证。这些特定于计划的验证将存储在计划的 Swift 容器中的 custom-validations 子目录中。将它们与计划一起存储是有意义的，因为这些验证可能特定于特定的部署计划配置，并且也使得导入/导出更容易。
由于自定义验证将作为计划的一部分存储，因此无需执行 CRUD 操作的额外工作流程/操作；我们可以简单地使用现有的计划创建/更新来实现此目的。
验证 Mistral 操作（例如 list 和 run_validation）需要更新以考虑这种新的验证结构。它们需要查找 tripleo-validations Swift 容器（用于默认验证）和计划的 custom-validations 子目录（用于自定义验证）中的验证，而不是像现在这样从磁盘上的目录中获取它们。
如果在默认验证和自定义验证中找到同名的验证，我们将始终选择存储在自定义验证中的验证。
注意
作为进一步的迭代，我们可以将验证作为独立的服务 Ansible 角色中的每个服务任务来实现。然后它们可以被 tripleo-heat-templates 服务模板消费。
替代方案¶
什么都不做。部署者已经可以引入额外的验证，只是不太方便且容易出错。
我们可以提供一个类似于
run-parts的已知目录结构，部署者可以在其中添加自己的验证目录。
安全影响¶
无
其他最终用户影响¶
为了添加自己的验证，部署者需要通过将 custom-validations 目录添加到部署计划，并确保该目录包含所需的自定义验证来更新部署计划。计划更新操作已在 CLI 和 UI 中得到支持。
性能影响¶
由于验证源现在是 Swift 容器，因此每次运行都可能需要下载验证。我们将密切关注这一点，并可能引入缓存，如果这成为一个问题的话。
其他部署者影响¶
无
开发人员影响¶
使用此更改，在开发和生产环境中测试和开发新的验证将更容易。
实现¶
负责人¶
- 主要负责人
akrivoka
- 其他贡献者
florianf
工作项¶
将默认存储迁移到 Swift 用于 tripleo-validations ([1])。
更新
load_validations和find_validation函数，以从本文档中指定的所有来源读取验证。
依赖项¶
为了能够实现此新功能，我们首先需要让验证使用 Swift 作为默认存储。换句话说，此规范依赖于蓝图 [1]。
测试¶
更改将在所有相关的 tripleo 仓库中进行单元测试（tripleo-common、instack-undercloud、tripleo-heat-templates 等）。
我们还可以添加一个新的 CI 场景，该场景将在计划中设置一个 custom-validations 目录。
文档影响¶
我们需要记录新 custom-validations 计划子目录的格式以及这将引入的新行为。
