Tempest 对 API 微版本测试的支持¶

https://blueprints.launchpad.net/tempest/+spec/api-microversions-testing-support

自从 Kilo 版本以来，nova 已经实现了 API 微版本，其他组件（Ironic 等）也已经实现了它。然而，目前 Tempest 没有任何对微版本支持，也没有进行任何测试。本提案旨在为 Tempest 添加微版本测试支持。

问题描述¶

在微版本机制中，每个微版本变更都非常小。例如，版本 2.2 的变更如下

Add 'type' to os-keypairs response
Change status code for os-keypairs create method from 200 to 201
Change status code for os-keypairs delete method from 202 to 204

从长远来看，将会实现大量的微版本，因为所有的 API 变更都应该通过微版本进行。现在 Ironic 也实现了这个微版本，其他项目也有计划实现它。因此，我们需要为这些项目实现一致的基本测试方法。

提议的变更¶

每个微版本的测试类¶

为每个微版本实现测试类。当添加一个更改 API 的新微版本时，基本上我们需要为该 API 实现一个测试类。此外，每个测试类都包含其微版本范围，类值如 min_microversion 和 max_microversion。例如，我们已经在 nova 的微版本 2.2 中向 os-keypairs 响应添加了一个新的属性 ‘type’，并且相应的测试类将是
```
class KeyPairsV22Test(base.BaseKeypairTest):
    min_microversion = '2.2'

    [..]
```
作为 os-keypairs 测试类。在上述情况下，不包含 max_microversion。这意味着 max_microversion 没有限制。如果我们再次使用微版本 ‘2.100’ 作为示例更改 API，则测试类将是
```
class KeyPairsV22Test(base.BaseKeypairTest):
    min_microversion = '2.2'
    max_microversion = '2.99'

    [..]
```
并且我们需要添加一个测试，例如
```
class KeyPairsV100Test(base.BaseKeypairTest):
    min_microversion = '2.100'

    [..]
```

添加配置选项以指定测试目标微版本。我们需要指定测试目标微版本，因为 OpenStack 云之间支持的微版本不同。为了在单个 Tempest 操作中运行多个微版本测试，配置选项应表示测试目标微版本的范围。新的配置选项也是 min_microversion 和 max_microversion，测试类将按以下方式选择

TestClass A: min_microversion = None,  max_microversion = 'latest'
TestClass B: min_microversion = None,  max_microversion = '2.2'
TestClass C: min_microversion = '2.3', max_microversion = 'latest'
TestClass D: min_microversion = '2.5', max_microversion = '2.10'

配置 (min, max)	测试类 (通过的微版本)
无, 无	A(未通过), B(未通过), C & D - 跳过
无, ‘2.3’	A(未通过), B(未通过), C(‘2.3’), D - 跳过
‘2.2’, ‘latest’	A(‘2.2’), B(‘2.2’), C(‘2.3’), D(‘2.5’)
‘2.2’, ‘2.3’	A(‘2.2’), B(‘2.2’), C(‘2.3’), D - 跳过
‘2.10’, ‘2.10’	A(‘2.10’), B - 跳过, C(‘2.10’), D(‘2.10’)
无, ‘latest’	A(未通过), B(未通过), C(‘2.3’), D(‘2.5’)
‘latest’, ‘latest’	A(‘latest’), B - 跳过, C(‘latest’), D - 跳过

因此，基本上配置 min_microversion 值会传递到微版本 header。但是，如果所选类的 min_microversion 较大，则会传递该类的 min_microversion。如果您想始终传递最大的微版本，则需要将 max_microversion 和 min_microversion 设置为相同的值，如上面的第 5 个示例。

默认配置值应为 (None, None)，如第一个示例，以便在不支持微版本的现有云上运行。因此，我们需要使用 openstack-dev/devstack 和 openstack-infra/project-config 更改配置值，以便在 gate 上运行微版本测试。

微版本 ‘latest’ 是一个魔术关键字，如最后一个示例所示。当将 ‘latest’ 作为微版本传递给每个组件（Nova 等）时，该组件将采取服务器端最新的微版本操作。有些微版本将不向后兼容，并且如果 Tempest 在当时不支持该微版本，则 ‘latest’ 操作可能会破坏 gate 测试。为了避免这种情况，我们不应在常规 gate 作业中指定 ‘latest’。指定它作为实验性作业是很好的，以了解我们需要更新 Tempest 以支持最新的微版本。

这些配置选项应为每个项目（Nova、Ironic 等）添加，因为不同项目之间的微版本号不同。

每个微版本的 JSON-Schema（Nova 特定）¶

定义每个微版本的响应。向后兼容的变更也需要 Nova 的微版本中的新版本，并且 Tempest 通过检查 Nova API 响应不包含任何额外的属性来验证它，使用了 JSON-Schema 的 additionalProperties 功能。因此，我们需要定义每个微版本的响应，并且 Tempest 需要通过微版本切换 JSON-Schema 的响应定义。现在，响应定义在 tempest_lib/api_schema/response/compute/ of tempest-lib 中，并且 v2.1 的一个基本微版本定义在 ./v2_1 下。每个微版本都与前一个版本略有不同，因此有必要在 ./v2_2、./v2_3 等下定义差异。
使服务客户端切换每个微版本的响应定义。Nova 的服务客户端将根据微版本切换定义。

Tempest-lib 迁移计划¶

步骤
1. 在 Tempest 中实现微版本测试框架。该框架包括基于提供的配置跳过方法等用于微版本测试。
2. 在 Tempest 中实现服务客户端的基础框架，以将微版本传递到请求 header。
3. 在 Tempest 中实现 Nova 微版本 v2.2 的测试用例作为示例。这包括模式和客户端更改。此时，我们可以测试微版本测试框架，并准备将其迁移到 tempest-lib。
4. 将微版本测试框架迁移到 tempest-lib

外部使用¶

一旦所有框架都迁移到 Tempest-lib，其他项目就可以将其用于他们的微版本测试。需要更新文档，说明如何使用一些示例的微版本测试框架。

项目¶

openstack/tempest
openstack/tempest-lib
openstack-dev/devstack
openstack-infra/project-config

实现¶

负责人¶

Ken’ichi Ohmichi <ken-oomichi@wx.jp.nec.com>
Ghanshyam Mann <ghanshyam.mann@nectechnologies.in>
Yuiko Takada <yui-takada@tg.jp.nec.com>

里程碑¶

完成目标里程碑: Mitaka-1

工作项¶

实现微版本的基本测试类
将测试目标微版本传递给服务客户端
添加单个微版本的测试类（作为示例）
将测试的微版本测试框架迁移到 Tempest-lib
从 Tempest-lib 消费这些接口并从 Tempest 中删除
更改 openstack-infra/project-config 上的 master 配置

依赖项¶

无

参考资料¶

https://review.openstack.org/#/c/242296/

Tempest 对 API 微版本测试的支持