Tempest 外部插件接口¶

https://blueprints.launchpad.net/tempest/+spec/external-plugin-interface

创建一个外部插件接口，以启用从树外加载额外的类似 Tempest 的测试，从而使项目能够维护其自身的树外测试。

问题描述¶

作为近期治理变更的一部分，旨在在“大帐篷”下重构 OpenStack，QA 计划需要能够处理涌入的“OpenStack”项目。作为这种转变的一部分，大多数 QA 项目正在从直接支持树内的每个项目转向为项目提供自助服务。缺失的一环是 Tempest 外部插件模型，所有其他 QA 项目都包含支持使用树外插件扩展功能的机制，但 Tempest 将负担放在用户身上来构建这些机制。展望未来，拥有一个统一的支持模型来启用这一点是必要的。

提议的变更¶

插件接口的第一步是处理插件中额外测试的加载。外部测试的额外路径需要传递给 unittest 发现机制。为此，将注册一个入口点，Tempest 可以在其运行命令中加载该入口点。这将使任何安装的包含 Tempest 入口点的 Python 包都能无缝发现并用作更广泛的“Tempest”测试套件的一部分。

在使用 pbr 时，您可以通过在 setup.cfg 中添加条目来注册入口点，如下所示：

[entry_points]
tempest.test_plugins =
    plugin_name = plugin_dir.config:load_plugin

这将向 Tempest 注册一个新的插件，以使用额外的测试。Tempest 侧的新 CLI 运行命令可能会利用 Stevedore 在运行时加载插件，以添加额外的部分。setup.cfg 中引用的钩子将返回用于 unittest 发现的测试路径。Tempest 中的 stevedore 管理器将使用此返回的路径来构建一组用于发现的测试路径，包括 Tempest 树内测试和所有已安装的插件，这将使运行 Tempest 时呈现统一的测试套件的外观。

至于插件本身，它们将包含几个关键部分，主要是测试和额外的配置。

从插件开始的基本目录结构示例如下所示：

plugin_dir/
  config.py
  tests/
    api/
    scenario/
  services/

但是，这只是建议的最低要求，它不会涵盖每个潜在插件的使用情况，因此插件中包含其他文件或目录是可以预期的。

这里的各个部分：

config.py 将包含两件事：第一是注册方法，它将提供 Tempest 执行插件所需的所有必要信息；第二是额外的配置选项。插件类上将有一个统一的方法，可能称为 register_opts()（以及 list_opts，以便我们有一个用于示例配置生成的调用），它将注册所有新的组和新的选项。这会将负担放在插件上，以根据需要创建选项的新组或扩展现有组。
tests 目录将包含实际的测试。上面的示例使用了两个子目录用于 API 测试和场景测试，但这并不是硬性要求。插件中的测试可以采用任何所需的组织方式。但是，使用单个父目录用于所有测试可以使 Tempest 中的测试发现逻辑更容易处理。
Services 将包含基于 tempest-lib 中的 RestClient 的额外的 API 客户端（如果需要）。

值得注意的是，我们应该努力使这些插件能够完全独立执行，并使用传统的测试运行器，而无需使用 Tempest。使用插件只是为了更容易地与更广泛的测试套件集成到其他项目中。一个 cookiecutter 仓库（作为现有的 devstack-plugin-cookiecutter 的一部分，或是一个单独的仓库）将被利用，以便为项目在最初设置新的 Tempest 插件时提供一个快速路径模板。

有一些东西来自 tempest-lib 是缺失的，但实际上是利用树外插件所需要的，主要是基础测试类 fixtures 和凭证提供者。这些不是开始插件工作的要求，因为插件可以暂时依赖 Tempest 代码来获取这些内容，但是，在中期，我们应该将这些迁移到 tempest-lib，以锁定使用它们的接口。

我们还将更改 Tempest 配置文件中的约定。传统上，我们说过不要依赖来自 Tempest 的配置选项，但这将随着插件的出现而改变，因为树外的代码将不得不依赖现有的选项作为构建的基础集。这意味着在未来，我们将不得不提供更好的保证来确保 Tempest 配置文件的稳定性。

替代方案¶

另一种方法是不使用可加载的入口点，而是将负担放在 Tempest 端用户身上来加载插件。因此，在调用 tempest run 时，您将同时指定要加载的插件列表。这种方法的缺点是用户需要知道插件在系统上的位置。而使用入口点只需要将额外的代码安装好，然后 Tempest 将自动使用外部位置。

此外，如果没有添加插件接口，任何人都可以使用 tempest-lib 和与插件中预期相同的机制来创建一个隔离的类似 Tempest 的测试套件。（事实上，几个项目已经这样做了）这之前也是树外 Tempest 测试的推荐方法。仅这样做的一个缺点是，所有内容都被视为隔离的，因此每个测试套件都必须单独处理。但是，考虑到 Tempest 中允许的范围现在已经明确定义，我们预计未来会添加更多这些外部套件。能够以单一方式处理它们，并使用单一的工作流程一次性处理所有这些套件，要理想得多，并且对最终用户负担更小。

项目¶

openstack/tempest
openstack/tempest-lib

实现¶

负责人¶

主要负责人: mtreinish

里程碑¶

完成目标里程碑: Liberty-2

工作项¶

添加对 tempest run 的支持，以加载已安装的入口点
修改 Tempest 文档，以概述项目范围和对树内 Tempest 策略的更改（包括配置文件更改等）
创建插件使用文档
将缺失的接口添加到 tempest-lib
创建 tempest-plugins 的 cookie-cutter 仓库

依赖项¶

在添加扩展加载支持之前，需要一个 Tempest 统一的 CLI，它添加了一个新的运行接口
可能需要向 unittest 添加一个额外的接口来处理发现点的列表。

Tempest 外部插件接口