在 Ubuntu 上自动化 Openstack 测试

 

2012 年 2 月 8 日

(原文链接)

在 Ubuntu precise 开发周期中，Canonical 平台服务器团队一直在致力于自动化在 Ubuntu 上对 OpenStack 进行测试。

这项工作的范围是

  1. 对 OpenStack trunk 进行提交时测试，以评估上游代码库的当前状态，以及与 Ubuntu precise 中的当前打包和当前 Juju charms 部署 OpenStack 的兼容性。
  2. 对 OpenStack Diablo 在 Ubuntu 11.10 上的 SRU 测试。

OpenStack 通过使用 gerrit 和 Jenkins 进行大量的预提交测试；我们希望通过 Ubuntu 重点测试来补充这些测试，为上游已经完成的测试提供另一个维度。

所以，喝杯咖啡，坐稳了；这篇阅读内容不短……

实验室设置

Ubuntu OpenStack QA 实验室由 12 台服务器组成；该解决方案的主要服务器是安装了 Ubuntu 11.10 的服务器，提供以下功能

  1. Juju – 用于在实验室中部署 OpenStack charms
  2. Cobbler 用于支持服务器配置（使用 Oneiric 中的 Ubuntu Orchestra 包）
  3. Jenkins CI – 提供基于上游提交到 github 仓库的触发，以及通用的作业控制和报告。
  4. Schroots 用于 Oneiric 和 Precise，以便本地构建软件包
  5. 一个 reprepro 管理的本地仓库，用于 Oneiric 和 Precise
  6. 基于 Squid 的存档缓存，以减少实验室中的安装时间

该服务器还充当进入和退出实验室的网关（它设置为 NAT 路由器）。

其他 11 台服务器已在 Cobbler 中注册；所有服务器都连接到 Sentry CDU（Cabinet Distribution Unit），允许从 Cobbler 完全控制电源 – 感谢 Andres Rodriguez 开发了 Cobbler 支持这种类型 CDU 所需的 fence 组件。

预配置 LVM 快照安装

启动新的集成测试运行需要关闭所有机器并从头开始重新配置。 我们的部署和测试运行必须能够应对上游提交的频率，尤其是在 OpenStack 接近里程碑和发布时，频率会增加。 在完成初始实验室设置后，我们能够拆除所有机器，重新配置并部署 OpenStack 大约需要 30 分钟。

重要的是，我们能够最大限度地减少完成测试周期所需的时间。 为此，我们采用了 LVM 快照和在 netboot 安装期间恢复根分区的方法。 过程如下

  1. 测试运行开始
  2. Juju 部署服务（例如 nova-compute）
  3. 机器通过 netboot 启动，并使用基于 LVM 的 Ubuntu 安装到 /dev/qalab/root
  4. 在安装结束时，根文件系统移动到 /dev/qalab/pristine-[release]-root，并在 /dev/qalab/root 创建快照
  5. 机器重新启动，运行 Juju 并部署 nova-compute 作为 OpenStack 部署的一部分。 此部署经过 smoke 测试。
  6. 下一个测试运行开始。 所有机器被终止。 Juju 重新部署 nova-compute，机器通过 netboot 启动，Ubuntu 安装启动。
  7. 安装检查 /dev/qalab/pristine-[release]-root 处是否存在逻辑卷。 如果存在，则在 /dev/qalab/root 创建新的快照并重新启动。 如果不存在，则继续安装并转到步骤 4。
  8. 系统重新启动，Juju 安装并重新部署 nova-compute 到新的 Ubuntu 安装。

此过程在所有节点上并行进行。 这样，我们能够将拆除和重新配置节点所需的时间从大约 30 分钟减少到 10 到 15 分钟，具体取决于正在部署的服务。

通过这种方法，我们还最大限度地减少了节点在安装过程中遇到存档不一致的几率。 这是开发版本中已知的问题，会在任何遇到它的节点上停止安装，导致整个部署失败。

所有这些都嵌入在 debian-installer 预配置中，通过 Cobbler 片段。 片段和 kick starts 可在 lp:~openstack-ubuntu-testing/+junk/cobbler-lvm-snapshot 处找到。

未来，我们将研究使用 kexec 作为快照恢复后的重启替代方案，以减少等待服务器启动的时间。 这应该进一步缩短测试周期。 感谢 James Blair 的想法（参见 http://amo-probos.org/post/11)。

Jenkins 管理

Jenkins 中的所有项目都使用 Jinja2 XML 模板和 python-jenkins (python-jenkins) 进行管理；这使得在实验室中设置新作业并根据需要重新配置现有作业变得非常容易（同时也提供了很棒的备份！）。

模板和管理脚本可在 lp:~openstack-ubuntu-testing/+junk/jenkins-qa-lab 处找到

在 Ubuntu Precise 上测试 Openstack Essex

这是第一个在实验室中设置的测试。 Jenkins（使用 git 插件）监视上游 github.com 仓库中 master 分支的提交。 当检测到更改时，将触发以下过程

构建

目标：验证上游 trunk 是否仍然可以与 Ubuntu 的当前打包一起构建。

  1. 基于上游组件的最新提交生成新的快照上游 tarball。
  2. 从 lp:~ubuntu-server-dev/<COMPONENT>/essex 拉取组件的最新存档打包。
  3. 将组件的测试打包中的任何更改从 lp:~openstack-ubuntu-testing/<COMPONENT>/essex 合并。
  4. 为新的上游提交自动创建新的 changelog 条目。
  5. 使用 sbuild 在干净的 schroot 中生成源包并进行构建。

假设软件包在本地构建成功

  1. 源包上传到测试 PPA（ppa:openstack-ubuntu-testing/testing）
  2. 将测试打包分支推回 lp:~openstack-ubuntu-testing/<COMPONENT>/essex。
  3. sbuild 的二进制包安装到本地 reprepro 管理的存档中。

此过程由单个脚本 (tarball.sh) 管理；感谢 Chuck Short 整合了过程的这一部分，该部分基于 Openstack 上游的工作。

对于 nova 项目的更改，然后执行部署阶段。

部署

目标：验证软件包是否可以安装、配置并达到已知良好的状态，然后再执行测试。

此阶段的测试使用 Juju 和 Cobbler 将 OpenStack 部署到 QA 实验室基础设施；它使用 OpenStack charms 的分支来支持使用本地存档，以及由 Adam Gandelman 编写的围绕 Juju 的部署器包装器，该包装器使用 Juju 执行实际部署并监视错误。

部署器配置为知道从哪里获取 OpenStack charms 的正确代码库，要部署哪些服务以及要在服务之间设置哪些关系。 正如上图所示，这并非易事，但 charms 和 Juju 完成了大部分艰巨的工作。

OpenStack 部署成功后，将执行测试阶段。

测试

目标：验证实验室中部署的 OpenStack 实际上可以工作！

此时，我们可以对新部署的云运行任何集成测试。 此测试能够帮助我们实现多个目标

  • 尽早发现破坏 Ubuntu 上 OpenStack 功能的上游错误
  • 验证 Ubuntu 开发版本中的打包分支与上游 trunk 兼容。
  • 使用这些软件包，验证我们的 Juju charms 是否正在部署功能正常的 OpenStack 云，并且是否已更新到上游的任何部署相关配置更改。

目前，此阶段如下所示

  1. 配置 OpenStack 部署（Adams 部署器脚本提供了一些用于在环境中定位特定服务的实用程序函数）
    • 为私有实例网络以及公共浮动 IP 池在 Nova 中创建网络配置。
    • 将图像上传到 Glance 服务器以供测试期间使用
    • 在 Keystone 服务器中创建 EC2 凭据以供测试期间使用。
  2. 运行 devstack 练习测试脚本，这些脚本可确保部署的基本功能。 目前，这包括
    • 基本的 euca-tools EC2 API，用于启动和停止实例
    • EC2 AMI 包上传
    • 浮动 IP 分配、关联和实例连接
    • 卷创建和附加到实例

注意：这些是当前针对 gerrit 上游提交运行的相同测试集。

从长远来看，我们计划在实验室中使用 OpenStack Tempest 测试套件；Adam 目前正在使其启动并运行。

报告

QA 实验室中的 Jenkins 实例不可公开访问；但是，实验室中运行的所有作业都发布到 http://jenkins.qa.ubuntu.com（使用 Jenkins build-publisher 插件），以便人们可以看到 Ubuntu precise 中测试打包的当前状态。

我们还在努力设置电子邮件通知。

迄今为止的成功

Juju charms 部署 OpenStack 组件，其配置与 Ubuntu 中打包更新之前的上游 trunk 兼容。 以前，软件包首先更新到存档中，而 Juju charm 更新滞后，因为在发现不兼容性之后。

我们于 Essex 第 3 个里程碑发布前 2 天启用了自动化测试。 我们能够发现并帮助修复上游中的一些错误，包括关键错误，例如 921784。 在过去，这些错误通常在发布后被发现（上游和 Ubuntu 中）。

自 E3 以来，通过此测试发现了更多关键错误并已在上游修复，其中一些仅适用于 Ubuntu 特定配置（上游未测试），并且会在代码命中 Ubuntu 存档后被用户发现（参见 922232）。

实验室的进一步计划

对稳定分支的更改进行预提交测试； Ubuntu Server 团队正在上游致力于维护已发布版本的 OpenStack 的稳定分支 – 这项工作将验证 review.openstack.org 中提出的补丁，以验证它们与已发布版本的 Ubuntu 中的当前打包是否兼容。 最初这将针对 Ubuntu 11.10 上的 Diablo，但在 Ubuntu 12.04 发布后也将支持 Essex。 理想情况下，测试过程将向 review.openstack.org 提供反馈，以帮助稳定发布团队审查提出的补丁。

参考文献

Jenkins 作业配置：lp:~openstack-ubuntu-testing/+junk/jenkins-qa-lab

支持实验室的脚本：lp:~openstack-ubuntu-testing/+junk/jenkins-scripts

LVM 快照预配置和 Cobbler 片段：lp:~openstack-ubuntu-testing/+junk/cobbler-lvm-snapshot

所有其他相关脚本、charm 分支等：https://code.launchpad.net/~openstack-ubuntu-testing/

鸣谢

整体交付管理和一般鞭策：Dave Walker

实验室安装和基本配置：Pete Graner、Tim Gardner、Brad Figg、James Page

网络电源控制服务器的 fence 代理：Andres Rodriguez

源包创建和构建过程：Chuck Short 和 James Page

使用 Juju 进行部署测试：Adam Gandelman

OpenStack 测试：Adam Gandelman

Jenkins 打包、配置和管理：James Page

预提交测试的 Gerrit 插件和通常很棒的想法：Monty Taylor 和 James Blair

撰写和审查此帖子：Adam Gandelman、Chuck Short 和 Dave Walker。

标签：

发表评论

您的电子邮件地址将不会被公开。 必填字段已标记 *