重新集成 Tempest-Lib¶

https://blueprints.launchpad.net/tempest/+spec/tempest-lib-reintegration

问题描述¶

在几个版本中，我们一直拥有 tempest-lib，它是一个独立的 Python 仓库和 Python 包，包含适合外部使用的稳定库接口。该项目的想法是将 Tempest 中的常见部分迁移到新的仓库中。然而，这个迁移过程以及将曾经存在于 Tempest 中的代码放在其他地方，给流程增加了许多摩擦。例如，在服务客户端迁移后，如果我们需要更新或添加一个需要客户端更改的测试，则需要在 tempest-lib 中提交更改，推送包含该更改的 tempest-lib 版本，提交 global-requirements 和 upper-constraints 的更新，然后我们才能在 Tempest 中使用该更改。这个过程已被证明非常昂贵，并且随着我们向 tempest-lib 迁移更多代码，导致了许多头痛。

提议的变更¶

拟议的更改是将当前存在于 tempest-lib 仓库中的所有库代码复制并迁移到 Tempest 仓库的 tempest/lib 中。然后，我们将像在 tempest-lib 中所做的那样，声明该目录下的所有公共接口为稳定接口。一旦代码位于命名空间中，任何进入 tempest.lib 的公共接口都将被假定为稳定接口。

tempest-lib 仓库将继续存在，但是，我们不会继续将迁移的代码推送到其中或维护带有语义版本控制的 passthrough 层在 tempest-lib 仓库中，而是会推送最终的 1.0.0 版本并将其标记为已弃用。我们将添加一个 Python 弃用警告，当使用 tempest-lib 时会发出该警告，以建议用户直接使用 tempest.lib。这意味着用户将继续像今天一样使用 tempest-lib，但如果他们想要任何错误修复或功能，则必须迁移到 Tempest 仓库中的新位置。通过这样做，我们可以避免维护 passthrough 层带来的维护开销。这也意味着我们不太可能通过尝试实现一个 passthrough 层而导致错误，从而破坏 tempest-lib 的用户。即使用户停留在 tempest-lib 上也不会出现任何问题，因为我们永远不会删除该仓库，只是在弃用和重新集成后，我们可能不会再推送任何版本或补丁。我们绝不会删除 tempest-lib 仓库或其 PyPI 发布版本。 我们很可能在弃用和重新集成后不会再推送任何版本或补丁。

Tempest-lib 的重新集成应该会稍微改变 Tempest 的发布节奏。此前，我们会在每个新的 OpenStack 版本开始时、Tempest 中出现重大新功能更改时以及稳定分支 EOL 时推送 Tempest 版本。然而，由于我们可能会更频繁地向库接口添加内容，因此版本更新可能会更频繁。Tempest 的版本控制方案将略有改变。我们将继续保持单调递增的整数，但我们还将拥有次要版本，以指示 tempest-lib 版本，以类似于语义版本控制的方式。例如，tempest-10.0.0 将指示支持 Mitaka 的系列中的第一个版本。然后，10.1.0 将是该系列中第一个 tempest.lib 版本，其中包含功能添加，而 10.0.1 将是在 Mitaka 版本发布后（但在功能版本发布之前）的 tempest.lib 错误修复版本。次要版本将在每个主要版本开始时重置为 0。继续前面的示例，在 Kilo EOL 时，版本将为 11.0，无论我们推送了多少 tempest.lib 版本更新。

Tempest-lib “迁移”实际上是稳定接口的努力仍然很有价值。但是，我们不必将所有代码迁移到外部仓库，而只需将代码移动到 Tempest 仓库的 tempest.lib 中。然后，我们可以根据需要添加 tempest-lib shim。

替代方案¶

维持现状¶

我们可以维持现状。这在很大程度上是可行的，但它给开发工作流程增加了许多摩擦。尤其是在我们尝试成熟或扩展现有接口时。这方面的完美例子是与涉及服务客户端的任何事情有关的例子。OpenStack API 随着时间的推移而演变（希望使用微版本），我们需要更新客户端以在测试中使用新功能，这变成了一个漫长而繁琐的过程。

创建一个 passthrough tempest-lib 包装器¶

我们可以保留 tempest-lib，但与其直接持有代码，不如将其作为对 tempest.lib 的 passthrough。这将出于两个原因，即与当前 tempest-lib 用户的向后兼容性以及启用库接口的语义版本控制。Tempest-lib 可以成为一个库，其中包含一个 shim passthrough，用于通过库接口公开的所有模块。然后，在将 lib 代码移回 Tempest 后，我们将开始 tempest-lib 的 1.x.x 版本系列。Tempest-lib 将在 requirements.txt 中依赖于 Tempest，我们可以控制 passthrough 在 tempest-lib 的 requirements 中使用的 Tempest 版本。例如，tempest-lib 中的 rest_client 模块最终会看起来像

from tempest.lib.common import rest_client

__all__ = ['RestClient', 'ResponseBody', 'ResponseBodyData',
           'ResponseBodyList']

class RestClient(rest_client.RestClient):
    pass

class ResponseBody(rest_client.ResponseBody):
    pass

class ResponseBodyData(rest_client.ResponseBodyData):
    pass

class ResponseBodyList(rest_client.ResponseBodyList):
    pass

实现¶

负责人¶

主要负责人: Matthew Treinish <mtreinish@kortar.org>

里程碑¶

完成目标里程碑: Mitaka 版本

工作项¶

接管 PyPI 上的 Tempest 所有权 [1]

启用将 Tempest 发布到 PyPI [2]

为 Tempest 和 Tempest-lib 添加 reno 发布说明

迭代重新集成：* 将 tempest-lib 中的所有代码移动到 Tempest 仓库的 tempest.lib 中

添加关于 lib 接口和新版本控制方案的 Tempest 文档

推送新的 Tempest 版本以标记 lib 的重新集成

添加 tempest-lib 弃用 Python 警告

推送 tempest-lib 版本 1.0

修改现有的迁移工具以适用于新的 lib 位置

依赖项¶

这不应依赖于任何其他工作，但是，它可能会与其他正在进行的 BP 发生冲突，尤其是与正在进行的 lib 迁移工作。

重新集成 Tempest-Lib