1 移除 trove-integration 和 redstack ¶

在最初，当 Trove 集成到 OpenStack 时，redstack 工具以及 Trove 具有一种非标准的结构（以 trove-integration 仓库的形式存在）是争论的焦点之一。

据我所知，当时技术委员会的规定之一就是将这种结构标准化。

由于多种原因（我们将在问题描述部分中描述），这种结构正在证明是一个相当大的麻烦，现在对项目来说这样做是有益的。

该项目的目标是通过正常的弃用流程来移除 trove-integration 项目和 redstack 工具。也就是说，现有版本，直到 Newton，将继续驱动并可能（我强调，可能）使用该工具，但从 Ocata 开始的新版本将不会使用。

Launchpad 蓝图：https://blueprints.launchpad.net/trove/+spec/eliminate-trove-integration-and-redstack

1.1 问题描述 ¶

trove-integration 项目是为存储创建、操作和测试 DBaaS 虚拟机脚本以及容纳用于管理开发环境的脚本而创建的。redstack 工具是瑞士军刀，它可以配置您的开发环境，制作客体镜像，加载它们，然后运行测试。

总的来说，这无疑是非常有用的。

它引入了几个严重的问题。

trove-integration 没有版本控制

它只有一个 master 分支。因此，所有对版本敏感的代码都必须通过巧妙的分支结构来实现。

trove-integration 是 trove 仓库之外的仓库

这带来了对 trove 仓库的依赖，例如当需要添加新的数据存储时，或者要添加新的数据存储版本时。Trove ‘元素’ 进入 trove-integration 但被 trove 使用。

CI 非常痛苦

由于 trove-integration 没有分支，我们必须针对不仅 master，而且针对稳定分支测试每个 trove-integration 分支。

版本控制变得更加复杂

我们现在必须处理多个操作系统（ubuntu 和 fedora）、多个版本（liberty、mitaka、newton、ocata、…）、不同版本的操作系统（trusty，现在是 xenial）。代码现在变得足够复杂，以至于尝试添加对 xenial 的支持（正如我为 SQL Server 所做的那样）变成了一场噩梦。

没有简单的方法来构建镜像

这是 Trove 用户面临的头号问题；如何构建镜像。提出了一种解决方案（https://review.openstack.org/#/c/312806/）可以通过创建 trove-image-builder 仓库来解决这个问题。该解决方案有一些优点和缺点，我们在此提出不同的解决方案（参见最终状态的第二条），它也将解决该问题。

redstack 是‘非标准’的

devstack 提供的模式/阶段方法在所有项目中都是标准化的，而 redstack 是少数（如果不是唯一）非标准方法。我们已经支持 devstack 插件，redstack（在配置堆栈用例中）不过是 devstack 的一个薄层。

1.2 提议的变更 ¶

提议的变更包含多个部分，并且其中一些部分与旨在针对 Trove 中的新功能或函数的蓝图期望的典型标题不匹配。因此，这些部分可能标记为不适用。根据需要添加了其他部分。

重要的是要强调的一点是，虽然此变更具有高度破坏性，并且会移动大量的代码，但我们主要是在一个地方移动几百个文件（元素）到另一个地方，并利用我们已经广泛使用的 devstack 插件。trove-integration 中的测试会受到影响，但我们已经在 trove 仓库之外进行大部分测试。

trove-integration 仓库中提出的变更；这些变更正在等待审查和合并将会受到负面影响。但无论我们选择何时进行此类变更，情况都会如此。大多数元素都高度参数化，为了使所有这些工作所需的实际更改是最小的。

我认为描述此提议变更的最佳方法是从描述提议的‘最终状态’开始。

1.2.1 提议的最终状态 ¶

trove-integration 中的元素将被合并到 trove 仓库中
这些元素现在将与服务器一起进行版本控制，它们位于同一个仓库中。标记 Ocata 版本也会导致为该版本发布一组元素，同样，标记 Pike 版本也会导致为该版本发布一组元素。

将提供一组工具来简化此操作，下面对此进行了描述。
将提供一组示例配置文件，这些配置文件将导致 devstack 安装和配置 Trove。用户可以将这些复制到自己的 localrc 中，或者在使用 devstack/stack.sh 之前使用命令来设置正确的环境变量。
trove devstack 插件将在 stack/extra 步骤中添加额外的代码，以构建和加载用户选择的一组客体镜像。将使用 trove 仓库中的元素构建这些镜像。

这将导致使用标准演示用户（而不是 alt_demo）。

在运行 devstack 时，必须配置 devstack 的配置文件，并且指定要构建和加载到 glance 中的数据存储的镜像以及在配置文件中注册 Trove。我最初考虑允许指定逗号分隔的列表，但单个数据存储可能是个好的起点。该数据存储也将设置为默认值。

将提供三个命令（trove-image-builder.bash、load-trove-image.bash 和 activate-trove-image.bash）。第一个将为您构建镜像。第二个将将其加载到 glance 并将其注册到 Trove，第三个将指定的数据存储/版本设置为默认值。
trove devstack 插件将在 stack/post-config 阶段添加额外的代码，以配置 Trove 测试环境，添加正确的 flavor，并执行 Trove 测试所需的其他操作。
已经存在于 trove 仓库中的场景测试将在不使用 redstack 工具的情况下运行。
Newton 及更早版本可能继续使用 trove-integration 和 redstack，Ocata 及更高版本将不使用 trove-integration 和 redstack。例如，Ocata 和未来的新元素将不会进入 trove-integration。这意味着在此过渡期间（可能持续两个版本），某些更改可能需要同时应用于 trove-integration 和 trove。
Ocata CI 将有一组新的作业，这些作业将利用这种新状态，不再使用 redstack 进行配置，并且 trove-integration 中正在进行的跨版本测试不再需要支持。

1.2.2 配置 ¶

将提供一些示例配置文件，这些配置文件将帮助用户在运行 stack.sh 之前配置他们的 localrc。这将导致 devstack 完全配置 Trove，并根据用户的指示构建和加载客体镜像。

1.2.3 如何实现 ¶

达到所需的最终状态将是一个多步骤的过程。

步骤 1

在某个特定时间点获取 trove-integration 仓库中的所有内容并将其放入 trove 仓库中。为了方便起见，我将将其放入名为 integration 的文件夹中。

最好这样做并保留历史记录，但这将非常痛苦。已经向 infra 邮件列表发送了请求寻求帮助，但与此同时，提交 https://review.openstack.org/#/c/384195/ 实现了我们需要的功能（没有历史记录）。

步骤 2

更改现在位于 trove 仓库中的内容，并使其能够像以前在 trove-integration 分支中一样执行 redstack 命令（将被重命名为 trovestack）。这还包括对文档的一些小修改。

提交 https://review.openstack.org/#/c/384746/ 实现了这一点。

步骤 3

重构 CI 作业以在 trove 树中使用 trovestack 而不是来自 trove-integration 树的 redstack。这意味着所有 CI 作业（或可能大部分）将成为遗留作业，并将为 Ocata 及更高版本创建新作业。

步骤 4

trovestack 中存在大量的杂乱代码，这些代码处理了 trove-integration 中的 redstack 没有版本控制并与每个 OpenStack 版本一起发布的事实。我们应该尽快进行此清理，因为我们很快将不得不处理 Ubuntu 16.04 的过渡，并且同时处理 OpenStack 版本和操作系统版本维度将非常难以管理。

步骤 5

获取 trovestack（以前的 redstack）的镜像构建方面，并使其成为一个独立的工具。https://review.openstack.org/#/c/374952/ 开始了这个过程，并将元素从它们被从 trove-integration 复制到的位置中移除，并开始使其成为一个独立的工具。我们将更新 trovestack 以使用此工具并避免镜像构建逻辑的重复。

获取镜像加载逻辑（包括设置默认数据存储），并使其成为一个独立的工具，并修改 trovestack 以使用该工具。

步骤 6

重构 CI 以自动为不同的数据存储构建镜像，并验证镜像构建过程是否正确。这将是一个新的作业。

步骤 7

将集成测试重构到 tests 目录中。