Ironic/Testing
目录
本地测试你的更改
如果你只想本地测试你的更改(你应该这样做),开发者指南提供了一个很好的起点。
上游 CI 测试
我们在 OpenStack CI 中运行了几类测试
- pep8 和 python 单元测试,从 Ironic 内部运行。
- Tempest API 测试
- http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/baremetal/base.py
- Devstack 启动 Ironic 服务并使用“fake”驱动程序创建节点。
- Tempest 运行 Ironic 的 API。
- 其他服务不涉及此测试,但可能由 devstack 启动。
- 功能测试,使用 Nova 与 Ironic 预置模拟硬件,也由 Tempest 运行。
- http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/test_baremetal_basic_ops.py
- Devstack 配置 Nova 使用 nova.virt.ironic 驱动程序,并启动所有 Ironic 服务。
- Devstack 创建虚拟机并将其注册到 Ironic
- Tempest 向 Nova 发出命令,并在 Ironic 中验证结果操作。
测试硬件驱动
驱动程序是 Ironic 架构的核心组件,但其中许多在没有访问专用硬件的情况下无法进行测试。例如,即使 IPMIToolPowerDriver 模块在没有访问具有支持至少 IPMI v1.5 的 BMC 的硬件的情况下也无法进行测试,而大多数笔记本电脑或工作站都没有此 BMC,并且无法模拟。因此,硬件驱动程序的供应商预计将为他们编写的驱动程序贡献 CI 资源。每个受支持驱动程序上 CI 测试状态的列表在 Ironic/Drivers 和/或 ThirdPartySystems 处维护。
以下是关于 Ironic 总体 CI 测试工作,以及关于第三方驱动程序的具体 CI 测试工作讨论。
第三方驱动要求
第三方(又称“供应商”)驱动程序是由于它们依赖于物理硬件的特定功能而无法在上游进行测试的驱动程序。如果它们满足以下要求,则此类驱动程序可以允许在 Ironic 中使用
- 每个驱动程序必须遵守现有的驱动程序接口。
- 驱动程序必须在与其他驱动程序的通用环境中运行。
- 每个驱动程序必须具有全面的单元测试覆盖率和足够的内联文档。单元测试应模拟任何第三方库,以便无需这些库即可运行它们。
- 供应商负责及时修复其驱动程序中的错误。
- 供应商提供支持的硬件平台上第三方、非投票测试。
- 供应商贡献(至少)一名开发人员参与上游参与。
这些指南正在不断发展,最初在此处提出:http://lists.openstack.org/pipermail/openstack-dev/2014-January/024823.html
第三方 CI
描述
Ironic 社区已经同意,如果供应商希望提交驱动程序,则该供应商还应要求设置其实验室中的第三方 CI 系统,该系统运行 适当的测试,针对其实际硬件进行 Ironic 补丁测试,并向 Gerrit 提供反馈。
第三方 CI 要求
- 请参阅官方 第三方测试 wiki。
- 测试您的公司在 Ironic 中集成的所有驱动程序。
- 发布所有测试结果。即使您有失败的结果,也需要发布这些结果。
例如,如果您的公司在 Ironic 中有两个驱动程序,您需要一个 CI 来针对这两个驱动程序进行测试,并为 Ironic 上游补丁报告每个驱动程序的测试结果。
现有的 CI 解决方案
- Puppet OpenStack CI
截止日期
- Mitaka-2:驱动程序团队将通过创建系统帐户并确定其 CI 团队的联系人来注册运行 CI 的意图
- Mitaka 功能冻结:所有驱动程序系统显示了接收事件并在沙盒中发布评论的能力。
- N 版本功能冻结:每个补丁测试和发布评论。
问题
- 加入 第三方会议
- 加入 #openstack-third-party-ci 并提出你的问题
常见问题解答
我应该使用哪些测试?
您应该有一个像 {pipeline}-tempest-dsvm-ironic-pxe_ipa{job-suffix} 这样的 Jenkins 任务
如何让我的 CI 在 gerrit 评论时重新运行?
如果发布以下评论到 gerrit 审查中,您的 CI 必须重新运行作业
<CI 名称>-recheck
因此,如果您的 CI 帐户名称是“vendor”,则 CI 应该能够通过留下评论重新触发
vendor-recheck
今天的 CI,使用我们刚刚描述的方案,看起来像:cisco-ironic-recheck、ufcg-oneview-recheck、ibm-powerkvm-recheck、hp-proliant-recheck、dell-ironic-recheck、fujitsu-irmc-recheck 等。
此外,您的 CI 还应支持传统的重新触发关键字,这是 第三方测试 wiki 所要求的。例如
recheck
在 layout.yaml 文件中,解析此文件的正则表达式应如下所示
trigger:
gerrit:
- event: patchset-created
- event: change-restored
- event: comment-added
comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*(recheck|oneview-recheck)\s*$
CI 不需要启动测试,直到 Jenkin's 给出 +1,但是否希望立即对所有补丁集触发,取决于维护者。
对于 openstack-ci 配置,更改以下内容以仅在 Jenkin's +1 时触发。
在 layout.yaml 中,删除该行
- event: patchset-created
然后添加
- event: comment-added
require-approval:
- verified: 1
username: Jenkins
如何运行我的 CI 来测试所有包含我的尚未合并驱动的 Ironic 补丁?
如果使用 devstack-gate,请使用 pre-test-hook 将您的驱动程序 cherry-pick 到正在审查的 Ironic 补丁之上。如果您已将更改提交到 gerrit,可以使用如下内容
function pre_test_hook {
echo "Cherry-picking latest driver from gerrit"
cd $BASE/new/ironic
# fetch latest patchset from gerrit
UPSTREAM_REMOTE=https://review.openstack.org/openstack/ironic
# set this to your gerrit change number
CHANGE_NUM=999999
PATCHSET_BASE=refs/changes/${CHANGE_NUM:(-2)}/$CHANGE_NUM
LATEST_PATCHSET=$(git ls-remote $UPSTREAM_REMOTE $PATCHSET_BASE/\* |
sort -t/ -k 5 -n | tail -n1 | cut -d$'\t' -f2)
if [ -z "$LATEST_PATCHSET" ]; then
echo "Failed to determine latest patchset of $PATCHSET_BASE from $UPSTREAM_REMOTE"
exit 1
fi
echo "Latest patchset ref is $LATEST_PATCHSET"
git fetch $UPSTREAM_REMOTE $LATEST_PATCHSET && git cherry-pick FETCH_HEAD
}
如果您尚未将更改提交到 gerrit,则必须从您自己的存储库(github 或其他)中获取更改。例如
function pre_test_hook {
echo "Cherry-picking latest driver from private repository"
cd $BASE/new/ironic
VENDOR_REMOTE=https://www.github.com/vendor/ironic-driver
REFSPEC=bp/new-ironic-driver
git fetch $VENDOR_REMOTE $REFSPEC && git cherry-pick FETCH_HEAD
}
否则,您可以在调用 stack.sh 之前进行更改,或通过自定义 devstack 插件 来进行更改。