跳转到： 导航, 搜索

CinderWallabyMidCycleSummary

简介

在 Wallaby 虚拟 PTG 上，我们决定举行两次中期会议，每次两个小时。第一次会议将在 Cinder 规格冻结之前举行，第二次会议将在新功能状态检查点附近举行。因此，中期会议将在 R-18 周和 R-9 周进行。

以下是讨论的简要总结。完整详细信息在 etherpad 上：https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles

第一次会议：R-18：2020年12月9日

我们通过 BlueJeans 从 UTC 14:00 到 16:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-wallaby-mid-cycles
录像: https://www.youtube.com/watch?v=rKmlpBTIDGA

Cinder 项目更新

即将到来的截止日期

  • 12月18日 - 规格冻结
  • 1月21日 - Wallaby Milestone-2 和新驱动程序合并截止日期
  • 3月1日 - os-brick wallaby 发布
  • 3月8日 - python-cinderclient wallaby 发布

稳定发布

我们目前在稳定分支上的发布节奏大约是每两个月一次。我们最近发布了

  • os-brick: 4.1.0 (wallaby), 3.0.4 (ussuri)
  • cinder: 17.0.1 (victoria), 16.2.1 (ussuri), 15.4.1 (train)

我们设法绕过了 Train 门，修复了一个关键的错误，但有三四个其他补丁已经被批准并针对 15.4.1，但卡在门上了。一旦我们解决了 Train 门的问题，我们很可能会以非正常节奏从 stable/train 发布额外的版本。

年末会议

今年的最后一次会议将在 12 月 23 日举行。由于也是本月的最后一次会议，将以视频会议形式举行。我们不会在 12 月 30 日开会。

需求/降低约束更新

最近由于 pip 更新引入了一个新的依赖关系解析器，该解析器似乎比旧版本更严格，因此 lower-constraints 作业被破坏了。结果，它检测到 cinder 指定的某些库的约束低于其依赖项允许的最小值。我们开始逐一更改 lower-constraints.txt 中的值，很快就变得明显，需要进行更大的更改。所以我们昨天合并了这个补丁：https://review.opendev.org/c/openstack/cinder/+/766085

该补丁将 requirements.txt 中的最小值提高到最近的 py38 testenv 的 pip freeze 中的版本，并相应地提高了 lower-constraints.txt 中的值。这包括一些库的主要版本的大幅提升，但它使我们的 lower-constraints.txt 更接近现实。lower-constraints 作业只是将 lower-constraints.txt 作为约束使用，并基本上检查是否可以满足需求并运行单元测试。由于功能和 tempest 测试以及第三方 CI 使用的库版本更接近 openstack 上限约束，这在我们声称的下限约束与实际测试内容之间留下了一个很大的差距。

操作
  • rosmaita - 调查 lower-constraints 的确切功能；它原本应该为打包者提供指导，但我们需要在声称的内容与实际测试内容之间保持平衡
  • 驱动程序维护者 - 检查驱动程序使用的依赖项的 setup.cfg 中的值，并确保最小值不要太低；还要确保 driver-requirements.txt 中的值与 setup.cfg 一致（setup.cfg 是实际使用的；driver-requirements.txt 是打包者的遗留便利文件）

Block Storage API v2 移除

本次会议的目标是制定任务/负责人/完成日期的列表，以便我们可以在本周期内推进此工作。Ivan (e0ne) 担任 v2 移除协调员。

使用 v2 的其他项目

tempest

tempest 是否使用 v2 由一个变量控制。Tempest 有一个 tempest-cinder-v2-api 作业：https://opendev.org/openstack/tempest/src/commit/dd84940a81316129bb6adccf7ae4b5cdcbb37382/zuul.d/project.yaml#L123 在 Wallaby 期间的某个时间点，tempest 将无法针对 cinder master 运行此作业。

行动
  • rosmaita - 与 gmann 讨论此事，并找出他希望如何处理更改
grenade
行动
  • e0ne - 正在调查中
devstack
操作
其他服务

Ivan 指出，当我们移除 v1 API 时，即使所有 cinder 测试都通过了，其他几个服务也崩溃了。因此，我们需要在禁用 v2 时测试 horizon、nova、glance 和 heat 门。

操作
openstackclient, openstackSDK

通知他们，如果他们计划继续支持 Block Storage API v2，他们将需要安排针对较旧 cinder 版本的测试。

操作
  • rosmaita - 通过 ML 联系 [osc][sdk]
其他？
操作
  • rosmaita - 向 ML 发出一般公告

在 Wallaby 中需要从 Cinder 中移除多少 v2 代码？

  • 我们需要移除 v2 端点。
  • v3 使用许多 v2 类，我们最终希望重构这些类。但在这样做之前，我们需要验证是否有良好的 v3 测试覆盖率。
  • 文档
    • 移除 v2 api-ref
    • 重构 api-ref 功能测试，仅处理 v3
    • 确保常规文档不包含任何 v2 特定的引用

cinder-tempest-plugin

操作

rosmaita - 如有必要，标记并修补，以确保仅运行 v3

python-cinderclient

我们已经在 ML 上宣布将在 Wallaby 中移除 v2 支持


这必须在客户端库冻结之前完成，即 3 月 8 日那周。

cinderclient 的结构类似于 Block Storage API，许多 v2 类被重用于 v3 功能。这可能会使从 CLI 移除 v2 功能变得棘手。

操作

某人 - 需要深入研究并了解需要做什么

一致且安全的策略

Keystone 在 Queens（增强范围）和 Rocky（默认角色）中进行了一些更改。将角色和范围结合起来，为 openstack 服务在默认策略配置中提供常见的“角色”。

有一个补丁描述了 cinder 将支持的角色，并提供了一个 cinder 策略矩阵，说明每个受支持的角色应如何默认行为：https://review.opendev.org/c/openstack/cinder/+/763306

这将为我们提供一个版本控制的文档，描述预期的行为，这将使验证新策略是否正确执行变得更容易。

在审查权限矩阵时，Rajat 注意到重置组快照状态的默认策略当前是 admin-or-owner，这似乎很奇怪。深入挖掘后发现，这可能是将旧的 policy.json 转换为代码中的策略时的一个错误

我们进行了一次快速讨论，看看是否有人记得这是有意的更改（没有人记得）。Eric 指出，将此暴露给最终用户可能很危险，如果他们将状态设置为“CREATING”之类的状态。共识是默认情况下这应该是一个管理操作，我们应该将当前值视为一个错误，并尽可能地将其回溯。

我们讨论了其他一些可能的更改，但关键要点是，即使“project-admin”角色在其名称中带有“admin”，但它也不是我们通常所说的“admin”。有关更多详细信息，请参阅权限矩阵补丁：https://review.opendev.org/c/openstack/cinder/+/763306

操作

Windows RBD os-brick 连接器

Lucian (lpetrut) 领导了对他在上周 Cinder 会议上提出的主题的后续讨论，即向 os-brick 添加一个混合类，为 Windows 提供一个简化的 RBD 连接器，因为 Ceph Pacific 将支持在 Windows 上挂载 RBD 镜像。


有一个担忧是 Windows RBD 连接器必须了解版本，或者应该通过连接属性传递版本信息。我们对此进行了一些讨论，但尚不清楚拥有此信息是否真的有用，并且它可能会通过连接器暴露我们不想暴露的信息。此外，Nova 可能会使用包含旧 Ceph 版本信息的缓存连接器属性。共识是目前我们不需要在连接信息中传递 Ceph 版本。

拟议规格的审查

启用复制状态的卷的迁移支持

https://review.opendev.org/c/openstack/cinder-specs/+/766130

问题是当前的工作流程不允许迁移具有过高堆栈中启用复制的卷。Cinder 当前处理 multiattach 的方式不是这里需要做的事情的良好模型。Gorka 建议应该像快照当前处理的那样完成此操作，通过调度器来确定是否允许该操作。他挖掘了两个旧补丁，来自快照更改为这样工作时

这看起来是新规格的一个有希望的模型。

存储卷格式信息

https://review.opendev.org/c/openstack/cinder-specs/+/760999

格式信息将存储为管理员元数据，但不应在 volume-show 调用中暴露；相反，它应该显示在 Attachments API 中。

我们简要讨论了“管理员元数据”应该是什么，因为它对于是管理员可以添加到卷的任意信息，还是用于管理卷的必需信息，存在歧义。共识是它应该更像后者；一些驱动程序使用管理员元数据来保存对它们自己有用的信息。因此，一般思路是

  • 驱动程序可以在管理员元数据中添加内容
  • 系统管理员可以查看以进行故障排除
  • 系统管理员不应修改他们自己未创建的字段

第二环节：R-9：2021年2月10日

我们通过 BlueJeans 从 UTC 14:00 到 16:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-wallaby-mid-cycles
录像

Cinder 项目业务

FS 后端格式信息文档头脑风暴

背景：在基于 NFS 的后端中，卷数据可以存储为原始文件或 qcow2 文件，理论上这对用户来说应该是透明的。Cinder 使用 qemu-img info 来确定卷存储的格式，然后再对卷执行操作。问题是，卷使用者可以将 qcow2 文件存储在其卷中，在这种情况下，Cinder 会被误导，认为该 *卷* 本身是 qcow2 格式，并据此采取行动，而 Cinder 应该将此视为原始格式文件。

解决此问题的 wallaby 规范是 https://review.opendev.org/c/openstack/cinder-specs/+/760999，它通过添加 volume-admin-metadata 来指定基于 NFS 的后端上表示卷的文件的“真实”格式来解决此问题。这里的问题是：我们如何处理基于 NFS 的后端上的旧卷？

  • 我们可以对卷执行 qemu-img info 并将结果存储为卷的格式。这个想法的问题是 qemu-img info 现在正在向我们提供不准确的信息（这就是我们有错误的原因），我们可能会存储不正确的结果，这将导致 cinder 对该卷进行操作时行为不正确
  • 达成共识是当前行为可能对旧卷来说是可以的
  • 关于如何在基于 NFS 的后端上管理卷存在一个问题。我们需要有一种方法将格式信息导入 cinder
  • 完全避免问题的另一种方法是将 nfs_qcow2_volumes 选项设置为 True，然后 Cinder 将假定基于 NFS 的后端上的所有卷都是 qcow2 文件，并将正确处理它们，无论卷内容如何。


Eric 提到我们需要确保这不会影响加密卷（可能不会，但我们应该确保）。一些当前的 NFS 加密补丁

从原始镜像创建卷时避免原始到原始的转换

Rajat 想讨论代码的这部分： https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L716-L720

从镜像创建卷时，我们会下载卷并将其转换为原始格式（因为 Glance 可以存储各种格式的镜像），然后再将其写入卷。显然，当 Glance 镜像已经是原始格式时，这样做是浪费的——不仅在 CPU 功耗上进行转换，而且在存储下载镜像的临时空间方面也是如此。运营商遇到过临时空间填满的问题。

与此同时，Eric 有一个 WIP 补丁，它将使用临时空间中的稀疏文件，以便在磁盘空间用完之前可以容纳更多的镜像。但另一个问题是 cinder 当前不会在尝试下载和转换过程之前检查可用空间量。我们可以先进行检查，然后再填满临时空间并崩溃。（这是一个对感兴趣的人开放的任务。）

这是一个定义明确的任务，可能适合作为谷歌夏季代码项目入门。（GSOC 提案导师方面的截止日期是 2 月 19 日。）

“ospurge”通过 openstackclient 通过 openstacksdk

有一个补丁添加了 openstackclient 的 purge 命令，该命令使用已合并到 openstacksdk 中的功能。Cinder 团队会很高兴审查它所做的事情并列出它需要的增强功能，以便使用它的运营商可以彻底清除正在删除的项目所消耗的资源。

这在邮件列表中出现过： http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019874.html 邮件中的用例是：“我想知道清理项目中所有资源的正确方法是什么，以便可以删除它？”

openstacksdk 中目前有代码可以对 cinder 执行 purge 操作： https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547

有一个补丁添加到 openstackclient 中，它在 OSC 中公开此功能： https://review.opendev.org/c/openstack/python-openstackclient/+/734485

我们快速查看了代码，看看还需要添加什么才能删除所有 cinder 资源和与项目关联的数据库记录。缺少的一些项目是

  • quotas
  • 组
  • 传输
  • 只有此项目具有访问权限的私有卷类型
  • 组快照
  • qos
  • 附件

此外，SDK 代码正在正确地先删除备份和快照，然后再删除卷，但它可以利用卷的级联删除功能，然后 cinder 将处理每个卷的备份和快照删除。Cinder 已经有很长时间了这种功能（在 v2 中，因此也在 v3.0 中，不需要使用微版本来使用它）。

有人提出了一个问题，关于与其他服务相比，序列（关于其他服务）是否正确，例如，您需要先删除实例，以便可以释放任何附加的卷。同样，如果 Glance 正在使用 cinder glance_store，您应该先删除镜像（这将删除卷）。这又引出了另一个问题，即如果其中一些镜像是公共的或与共享的其他项目共享，您想怎么做？当前策略可能只能很好地解决一个用例，但可能会让运营商在其他用例中处于不利地位。

讨论的结论是 cinder 社区中的某人有机会“接口”与 OSC、OSDK 团队合作，以制定一个有用的项目清除功能，并找出 python-cinderclient 和 OSC 之间的功能差距，以及 OpenStack SDK 中正在实现的内容。

重构 cinder.utils / volume_utils

Eric 想提出这个问题，该问题在之前的 cinder 会议上讨论过，提醒我们我们同意这是一个好主意，并且有一些补丁需要审查，如下所示


请注意，这些补丁与新的驱动程序补丁之间可能存在竞争条件，这可能需要进行一些更改。

Block Storage API v2 移除

我们仍然致力于这样做。

rosmaita 将发布一个补丁，从 python-cinderclient 中删除 v2 支持。

e0ne 将在下一次 cinder 会议上报告删除 cinder 中 v2 的状态。

备份驱动程序与容器参数相关的问题

Gorka 在邮件列表中讨论了这个问题： http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020124.html

共识是 Gorka 发现了一个真正的问题，并且他提出的解决方案是合理的，即

  • 创建一个策略来接受 API 上的 `container` 参数（默认允许以实现向后兼容性）。
    • 也许删除此参数并引入一个新参数：--backup-options，它将具有后端特定的选项
  • 添加一个新的配置选项 `backup_container_regex` 来控制 `container` 的可接受值（默认值为 `.*` 以实现向后兼容性）。
    • 可以在 API 级别出错；可以在响应中包含正则表达式，说明“您的容器必须命名为这样”
    • 这将在策略检查之后发生，以查看用户是否允许指定容器

一致且安全的 RBAC 状态

  • 事实证明，Block Storage API 的 URL 结构（在路径中包含 project_id）是使用系统范围令牌的一个问题
  • 我们需要就每个策略的每个“角色”应该是什么行为达成一致
  • 问题：项目读取者是否能够看到附件中的密码？
  • 问题：“读取者”角色应该只“看到”相同的数据，无论范围如何吗？

mypy

Eric 提醒我们，我们之前同意在 cinder 代码中添加类型注释，但补丁仍然停在那里。

我们试图通过让人们自愿负责特定的补丁来推进这个过程： http://eavesdrop.openstack.org/meetings/cinder/2020/cinder.2020-11-18-14.00.log.html#l-50

那是 2020 年 11 月（！）我们同意每个人都应该履行他们的承诺并尽快合并这些补丁。

使用当前版本的 Ceph 进行测试

Eric 注意到 Red Hat 已经开始使用 Ceph Pacific（目前在 RC 中）进行测试，并且报告了一些错误。我们需要一种在上游 Cinder 中确保我们及早测试更新的 Ceph 的方法，以便及时发现问题。

Ceph 每年发布一次，最新的 ceph RC 在 openstack 春季周期 M-2 左右发布。因此，在这个时间点进行一些测试，运行一些测试，看看是否有任何问题会很好，因为在 OpenStack 协调发布时，最新的 Ceph 已经可用大约一个月了。

  • 需要弄清楚配置使用 Ceph $VERSION 的作业有多容易
  • 如果真的那么简单，我们是否应该对所有 cinder 支持的 ceph 版本进行定期作业？（我们支持 Ceph+2，即当前支持的 ceph 版本（两个）加上接下来的两个旧版本——但我们目前只测试一个版本（通常是最新的）。或者这是否太过分了？
  • 短期行动：将此添加到发布周期任务中
  • 长期：弄清楚更具体的内容

审查 XS 补丁

Eric 指出新的 Gerrit 界面对补丁进行 T 恤尺寸划分，并且有很多超小的补丁停在那里，如果我们团队承诺审查它们，可以很快地获得审查。例如： https://review.opendev.org/q/project:openstack/cinder+AND+status:open+AND+size:%253C%253D10

此外，其中一些补丁虽然很小，但解决了我们应该尽快修复的一些严重错误。每个人都同意我们应该尽快解决这个问题，但仅仅在上述链接中查看评论的良好意图是不够的。因此，我们决定可以进行某种审查会议，在特定的时间进行视频会议并进行审查。第一次会议将在下周五（即 2 月 19 日）进行 2 小时。我们会看看情况如何，并在完成第一次会议后确定这些会议的频率。

公告： http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020433.html

CI 失败 unittest

Sofia 指出最近的更改（已经回溯）给单元测试引入了不稳定性。她有一个补丁来解决这个问题： https://review.opendev.org/c/openstack/cinder/+/774496/

在修复合并之前，我们可能会看到 master 分支上的作业失败。因此需要快速审查，并在修复补丁进入稳定分支后进行移植。

R-9 Bug Review

Sofia 提到，在 R-9 周，总共有 6 个新 bug：5 个是 Cinder 的（全部与驱动相关），还有一个来自 os-brick：https://etherpad.opendev.org/p/cinder-wallaby-r9-bug-review

os-brick 相关的 bug 看起来有点令人担忧：https://bugs.launchpad.net/os-brick/+bug/1915196

但 Eric 认为这可能是一个推测性的 bug，因为看起来我们已经有代码来解决这个问题：https://opendev.org/openstack/os-brick/src/branch/master/os_brick/initiator/linuxscsi.py#L635

Hacking update

Eric 已经提交了补丁来更新 Cinder 正在使用的 hacking 版本：https://review.opendev.org/c/openstack/cinder/+/770145

他认为可能已经有类似的补丁用于其他 Cinder 发布仓库。

Eric 还提交了一个补丁来更新我们与 Cinder 一起使用的 pylint 版本：https://review.opendev.org/c/openstack/cinder/+/771508

保持 pylint 更新是一个好主意；更新后的 pylint 版本发现了一些潜在的 bug。

从 "https://wiki.openstack.org/w/index.php?title=CinderWallabyMidCycleSummary&oldid=177627" 检索