跳转到： 导航, 搜索

Cinder/tested-3rdParty-drivers

驱动程序测试

描述

Cinder 社区（以及其他 OpenStack 项目）已经达成共识，如果供应商希望提交其特定存储设备的驱动程序，则该供应商还应要求在其实验室中设置一个第三方 CI 系统，该系统针对 Cinder 项目的每个相关提交（通常是 cinder 和 os-brick）运行 Tempest，并向 Gerrit 提供反馈。

第三方 CI 要求

  • 请参阅官方 第三方测试 wiki。
  • 测试您的公司在 Cinder 中集成的所有 volume/backup/connector 驱动程序，以及每个受支持的后端。
  • 在 cinder 和 os-brick 的每次更改时运行。（Cinder 测试使用 os-brick 的最新发布版本，因此如果您没有检查，os-brick master 的不良更改可能会溜进来。）
  • 发布所有测试结果。即使您有失败的结果，也需要发布这些结果。
    • 发布的结果必须可以直接从网络上浏览，以便审阅者可以轻松查看。不要发布需要下载的归档文件链接。
  • 测试您的解决方案使用的所有 fabric。
  • 设置您的 CI，如果它被 触发，则重新运行。
  • 您必须使用当前开发周期的至少一种 Python 运行时执行您的测试。
    • 当前的 Python 运行时由 OpenStack 技术委员会确定。请参阅 OpenStack 管理文档中的 测试运行时。


例如，如果您的公司在 Cinder 中有两个 volume 驱动程序，并且它们都使用 ISCSI 和 FibreChannel，那么您需要一个 CI 来针对四个后端进行测试，并报告每个后端的每个 Cinder 上游补丁的结果。同样，如果您的公司有一个 volume 驱动程序支持两个不同的后端，那么您需要一个 CI 来针对这两个后端测试该驱动程序，并报告每个后端的每个 Cinder 上游补丁的结果。

现有的 CI 解决方案

您使用的 CI 解决方案完全由您决定。

也就是说，我们（Cinder 项目团队）有兴趣培养一个第三方 CI 维护者社区，以便人们可以更轻松地设置和维护 CI 系统。（因为发生的情况是，一个 CI 被建立起来，工作得很好，设置它的人转移到其他职责（在同一公司或其它地方），突然有一天它不再报告，并且新的人必须争先恐后地弄清楚如何修复它，而事情正在发生。）

  • 我们当前的（截至 2020 年 1 月）建议是：Software Factory
    • 它正在被 RDO 用于他们的 CI 系统
    • Software Factory Operator Documentation（有很多其他的文档和指南，但这对快速浏览来说很好）
    • 如果您尝试使用它，请在 IRC (#openstack-cinder) 或邮件列表中或在此 wiki 页面上向我们提供反馈

当前报告 Cinder CI

请参阅列表：http://cinderstats.ivehearditbothways.com/cireport.txt

不合规策略

当前的 CI 合规策略是

  • CI 必须报告每个补丁，无论代码更改是否在他们自己的驱动程序代码中
  • CI 注释必须正确格式化，以便在 gerrit 的 CI 摘要中显示


如果

  • 在两周内没有 CI 成功报告
  • 发现 CI 没有测试预期的驱动程序（CI 使用默认 LVM 驱动程序等）
  • 发现其他问题但未及时解决

注意：如果 CI 停机任何一段时间，请在 #openstack-cinder IRC 中发表评论，告知团队。这并不意味着它将免于不合规策略，但它会让我们知道您意识到您的 CI 停机并且您正在努力解决它。

如果发现驱动程序 CI 不合规

  • 将提交一个驱动程序补丁将其标记为不受支持
    • 这将导致 c-vol 日志中记录警告消息，表明它不受支持且已弃用
    • 操作员需要在 cinder.conf 中设置 enable_unsupported_drivers=True，否则服务将无法加载
  • 如果问题未在下一个版本之前解决，该驱动程序将受到删除。请参阅 Cinder 驱动程序删除策略 以获取详细信息

CI 结果将定期审核，如果发现不合规，驱动程序将被标记。我们将在发布的第三个里程碑左右进行最终审核。如果标记为不受支持，供应商需要在 RC 标签之前合规。如果及时解决，可以撤销该标记。

CI 结果目前发布在这里：http://cinderstats.ivehearditbothways.com/cireport.txt

问题

  • 加入 第三方会议
  • 联系 IRC 昵称 DuncanT 或 asselin 在 Freenode #openstack-cinder 上。

常见问题解答

我应该使用哪些测试？

您必须使用两者


Tempest 将在运行时自动发现所有已安装的插件。因此，只需安装包含 cinder-tempest-plugin 的 python 包，您就可以使用 Tempest，无需进行其他操作。

Volume 和 Connector 驱动程序

可以使用以下命令从 Tempest 仓库启动 volume 相关测试

tox -e all -- volume | tee -a console.log.out

对于使用 devstack-gate 的用户，请在运行作业之前导出此变量

export DEVSTACK_GATE_TEMPEST_REGEX="volume"
备份驱动程序
tox -e all -- volume_backup | tee -a console.log.out

对于使用 devstack-gate 的用户，请在运行作业之前导出此变量

export DEVSTACK_GATE_TEMPEST_REGEX="volume_backup"

如何配置 DevStack 以使我的驱动程序通过 Tempest 测试？

DevStack 设置的 sample local.conf。

对于 cinder

[[local|localrc]]
ADMIN_PASSWORD=password
MYSQL_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
SERVICE_TOKEN=password

# These options define  expected driver capabilities
TEMPEST_VOLUME_DRIVER=foo
TEMPEST_VOLUME_VENDOR="Foo Inc"
TEMPEST_STORAGE_PROTOCOL=iSCSI

# These options allow you to specify a branch other than "master" be used
CINDER_REPO=https://opendev.org/openstack/cinder
CINDER_BRANCH=refs/changes/83/72183/4

# Disable security groups entirely
Q_USE_SECGROUP=False
LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
CINDER_SECURE_DELETE=False

[[post-config|$CINDER_CONF]]
volume_driver=cinder.volume.drivers.foo.FooDriver

对于 os-brick

[[local|localrc]]
ADMIN_PASSWORD=password
MYSQL_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
SERVICE_TOKEN=password

# These options define  expected driver capabilities
TEMPEST_VOLUME_DRIVER=foo
TEMPEST_VOLUME_VENDOR="Foo Inc"
TEMPEST_STORAGE_PROTOCOL=iSCSI

# These options allow you to specify a branch other than "master" be used
OS_BRICK_REPO=https://review.opendev.org/openstack/os-brick
OS_BRICK_BRANCH=refs/changes/85/873085/1
LIBS_FROM_GIT=os-brick

# Disable security groups entirely
Q_USE_SECGROUP=False
LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
CINDER_SECURE_DELETE=False

[[post-config|$CINDER_CONF]]
volume_driver=cinder.volume.drivers.foo.FooDriver

我应该测试哪些更改？

您应该测试 cinder 和 os-brick 的所有更改。

  • 您希望保护自己免受 cinder 更改的影响，这些更改可能会影响您的驱动程序。请注意，由于第三方 CI 系统是非投票的，因此失败不会阻止补丁合并。审阅者通常会在专门针对您的驱动程序代码的更改中检查您的第三方 CI 结果，但他们可能不会注意到直接不接触您的驱动程序的 main cinder 代码的补丁。因此，重要的是您关注 CI 的失败，如果确实是失败，则添加手动 -1。
  • 在 cinder CI 测试中使用的 os-brick 是 os-brick 的最新适当的发布版本。因此，os-brick 中可能会发生影响您的驱动程序功能的更改。如果您没有测试 os-brick 更改，您将无法在下一个 os-brick 版本发布之前发现这些问题，这对您的客户来说将非常糟糕。
  • 注意：对第三方 CI 测试 os-brick 更改的期望之前没有明确传达，因此有些驱动程序测试，有些不测试。因此，这并非在 OpenStack 2023.1 版本开发周期（即 Zed 版本的下一个周期）之前是硬性要求。

如何运行我的 CI 以测试所有 cinder 补丁，而我的驱动程序尚未合并？

如果使用 devstack-gate，请使用 pre-test-hook 将您的驱动程序 cherry-pick 到正在审核的 cinder 补丁之上。如果您已将更改提交到 gerrit，可以使用如下内容

function pre_test_hook {
    echo "Cherry-picking latest driver from gerrit"
    cd $BASE/new/cinder

    # fetch latest patchset from gerrit
    UPSTREAM_REMOTE=https://opendev.org/openstack/cinder

    # 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/cinder

    VENDOR_REMOTE=https://www.github.com/vendor/cinder-driver
    REFSPEC=bp/new-cinder-driver

    git fetch $VENDOR_REMOTE $REFSPEC && git cherry-pick FETCH_HEAD
}

否则，您可以在调用 stack.sh 之前或通过自定义 devstack 插件 进行更改。

何时需要第三方 CI 投票？

一旦第三方 CI 变得更加常见和稳定，我们将重新审视这个问题。这在 讨论 中于 2014 年 10 月 15 日达成一致。在 讨论 中于 2015 年 4 月 8 日达成一致，即拥有 Infra 托管 CI 的开源解决方案可以有机会投票。

截至 2022 年 7 月，第三方 CI 系统不幸不稳定，因此投票是不可能的。

如何测试 FC 驱动程序？

使用 PCI 直通将 VM 提供对 FC PCI 设备的访问权限。脚本可在以下位置获取：https://opendev.org/x/third-party-ci-tools/src/branch/master/provisioning_scripts/fibre_channel

如何通过 gerrit 注释触发我的 CI 重新运行？

如果 Gerrit 评论中发布了以下注释，则需要您的 CI 重新运行作业

"run-<CI 名称>"

因此，如果您的 CI 帐户名称是“Super Cool Storage CI”，则可以通过留下以下注释来重新触发 CI

run-Super Cool Storage CI

CI 不需要等到 Zuul 给出 +1 后才启动测试，但维护者决定是否希望立即在所有补丁集上触发。

对于 openstack-ci 配置，更改以下内容以切换为仅在 Zuul 给出 +1 时触发

在 layout.yaml 中：删除该行

      - event: patchset-created

然后添加

      - event: comment-added
        require-approval:
            - verified: 1
              username: zuul

稳定分支测试呢？

当前策略在此帖子中描述在 openstack-discuss 邮件列表中：http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027021.html

这是一个我们正在寻找的示例：https://review.opendev.org/c/openstack/cinder/+/821893/

从 "https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers&oldid=182688" 检索