跳转到： 导航, 搜索

CinderVictoriaPTGSummary

目录

简介

此页面包含 Cinder 项目在 2020 年 6 月 2 日至 5 日举行的 Victoria PTG 期间会议中讨论的主题的摘要。

Cinder 团队在 2020 年 6 月的 Victoria（虚拟）PTG。


本文档旨在提供每个会议的摘要。更多信息可在 cinder PTG etherpad 上找到


会话已录制，因此要获取任何讨论的全部详细信息，您可以观看/收听录制内容。录制链接位于下面的适当位置。

周二 6月2日：当前 Cinder 问题

录像

讨论附加卷暴露主机信息给非管理员时的安全问题

讨论由 whoami-rajat 领导

这与 https://bugs.launchpad.net/cinder/+bug/1740950 和 相关错误：https://bugs.launchpad.net/cinder/+bug/1736773

计算主机在卷详情响应中泄露，也在 REST 附件 API 中。

我们已经同意卷详情响应仅在以管理员身份调用时才显示主机（API 响应已经允许为空值，因此不需要 API 更改）。

对于附件 API 响应，需要进行一些研究，以了解是否需要此字段以及在什么上下文中需要。看起来 Nova 不需要它，看起来我们的 os-brick 连接器也没有使用它，但另一方面，此信息已经存在于响应中很长时间了，我们需要小心，因为可能有东西正在使用它。我们需要小心响应中省略的信息，因为如果限制过多，调用者将无法连接到后端。

结论

  • 短期内，需要制定策略来管理此问题
  • 未解决的问题：该建议是保持默认行为，但这仍然允许泄露计算主机名；可能最好采用更严格的策略（因为我们不相信任何服务依赖它），然后让操作员调整策略以允许需要此信息的用例的用户查看它
  • 操作 - whoami-rajat 将继续处理此问题

加密卷的容量规划

讨论由 eharney 和 enriquetaso 领导

创建加密卷时，LUKS 标头会占用一些空间。这在一些迁移错误中显示出来。如果您有一个未加密的卷并迁移到加密类型，则会失败，因为目标上没有足够的空间来容纳整个源卷。


丢失的确切空间量尚不清楚，它可能因 luks 格式以及 iscsi (cryptsetup) 与 rbd (luks) 而异。它可能在 1-2 MB 左右，但我们以 GB 为单位分配空间。是否可以进行非常细粒度的空间分配可能取决于包含卷的后端。我们还需要保留千兆字节边界以进行会计目的（使用情况、配额、费用等），因为这是每个人工具所期望的。

Walt 建议我们在卷迁移期间允许指定新的大小。对于 retype，Gorka 建议我们可以在 retype 请求中添加一个类似于当前 migration_policy 的标志，该标志让用户可以选择如果需要迁移，则可以执行迁移。我们可以有一个标志，指示如果 retype 要成功，则可以增加卷的大小。这样我们就不会在用户不知情的情况下进行操作——如果卷不合适，我们会失败，并允许他们 retype 到新大小（如果他们希望 retype 成功）。

结论

  • 采用 Walt/Gorka 的方法。这将允许我们修复许多错误，如果将来有需求，我们可以迁移到更复杂的东西。
  • 操作 - Sofia - 在文档中添加说明，说明将未加密的卷重新类型化为相同大小的加密卷很可能会失败（以便用户知道不要在旧版本中尝试此操作）

配额！！！

讨论由 rosmaita 领导

问题是代码中存在竞争条件和错误，因此操作员会看到配额表中重复条目、不正确的用法报告等。

有一个规范建议删除配额使用缓存（数据库表）：https://review.opendev.org/730701

想法是，与其尝试更新此表，不如在运行时确定使用情况。有些人怀疑这可能会导致性能问题，但 Eric 认为，通过适当的索引，数据库可以非常快速地计算出这一点。与实际构建卷所需的时间相比，这绝对是一个非常小的数字。

我们可能仍然需要担心使用新方法的一些竞争条件。我们的用法代码基于 Nova 的，但他们已经重写了他们的代码以消除数据库表。但他们也接受偶尔用户超过配额是可以的。我们可能需要做类似的事情。

讨论中出现两个相关问题

  • keystone “统一限制”工作——这与用户限制存储在何处有关，但不影响用法计算。将用户限制移动到 keystone 将是一项独立的工作
  • REST API 当前为用法返回 413 或 500。API SIG 建议返回 403 而不是 413，但似乎没有理由更改。 （您需要一个新的微版本才能返回“正确”的响应代码，但如果该微版本不可用，您仍然需要能够处理“不正确”的响应代码，因此为什么不坚持我们所拥有的。）但是，应该修复 500。

结论

  • 在 https://review.opendev.org/730701 中的方法看起来很有希望。如果我们可以获得一些性能数字来评估更改的影响，那就太好了。
  • 需要弄清楚我们将看到哪些新的竞争条件以及如何处理它们。 （查看 Nova 所做的事情应该有所帮助。）
  • 操作 - 继续讨论规范


（团队提前结束，以便 Cinder 核心安全团队可以审查补丁并计划推出修复 Launchpad Bug #1823200 的补丁，该补丁将于第二天公开发布。）

周三 6月3日：第三方驱动程序

录像

错误：使用通用 NFS 驱动程序扩展附加卷失败

讨论由 lseki 领导

错误：https://bugs.launchpad.net/cinder/+bug/1870367

它会影响依赖通用 NFS 实现的 Quobyte 和 NetApp 驱动程序，我们需要分两步修复它

(1) 不允许对 nfs 驱动程序扩展附加卷：https://review.opendev.org/#/c/725805/

(2) 找出如何安全地进行在线扩展，然后重新启用该功能

这曾经有效，但已经停止。怀疑 qemu、qemu-img 的更改似乎正在进行更多的锁定（版本 2.10、2.11，大约在那个地方）。假设是 nova 锁定文件，然后 cinder 进程无法写入它。

我们需要研究是否有我们可以要求 nova 执行的 qemu 操作，例如：

virsh qemu-monitor-command <DOMAIN> --hmp "block_resize <DISK> 2G"

想法是模拟快照，您有一个通过 libvirt 实现的 nova API。

结论

  • 继续两阶段方法，即阻止 nfs 驱动程序的该操作，这样您就不会遇到故障，并研究如何实际修复它
  • 似乎我们需要 nova 的合作，我们不应该尝试自己绕过锁定
  • 测试：我们在 cinder gates 中运行 devstack-plugin-nfs-tempest-full；准备好后，应在作业中启用 volume-feature-enabled.extend_attached_volume

LVM 卷驱动程序的改进建议，通过 cinder 直接附加存储

提议者不可用，但我们还是讨论了这个问题，因为它已经出现了很多次。


基本思想是，如果您位于同一节点上，则可以通过将卷作为设备打开来获得一些优化，从而跳过 iSCSI 层。问题是这是一个非常特殊的情况。

团队讨论了几种方法

  • 在 LVM 驱动程序中引入此优化，如果您位于同一节点上，则跳过 iscsi 层
    • 优点：将允许更多功能
    • 缺点：使驱动程序更复杂，更容易引入错误
  • 在 cinder 中添加一个选项以启用 LVM 驱动程序上的“尝试本地连接”
    • 如果启用，则将路径添加到连接信息
    • 如果 os-brick 收到路径，则尝试使用它（如果存在），如果不存在，则执行正常的 iSCSI 连接
  • 在 lio 目标中做类似的事情


项目对这个有什么态度？

  • 如果是新的目标，可以克隆 lio 作业并运行这些测试（因为它是一个单节点案例）
    • 需要有良好的文档，尤其是关于限制
  • 如果采用“可选”方法，它将使用相同的 lio 作业，但设置“尝试本地连接”配置
  • 底线是我们希望尽可能减少对其他驱动程序的影响

结论

  • 我们想更多地了解用例——这确实听起来像是使用 cinder 来管理 nova 临时存储
  • 提议者在解决上述问题后可以再次提出此问题

Ceph iSCSI 驱动程序

讨论由 hemna 领导

Walt 一段时间前开始这项工作，但由于一些依赖项未打包成发行版，因此无法获得基础设施批准的 CI，所以工作停滞了。

四月份邮件列表中再次讨论了这个问题：http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014278.html

Walt 今天早上写了一个更新：http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015237.html

Ubuntu Focal 现在有了软件包，所以我们可以以 Focal 作为 CI 目标。Fedora 的软件包可能很快也会发布。

目前正在努力将 ceph devstack 插件更新到 ceph 的现代版本：https://review.opendev.org/#/c/676722/ -- 帮助合并这个补丁会很好，这样我们就可以使用现代的 ceph 了。

结论

  • Walt 现在有时间继续这项工作了；他将与 Linaro 开发者协调合作。

移除卷驱动程序 abc 类

由 eharney 领导的讨论

基础驱动程序的设计包括许多接口作为抽象类，例如：https://opendev.org/openstack/cinder/src/commit/be9d5f3fa54b1b7948f44a9c91cf3f4753c0a03b/cinder/volume/driver.py#L1998

这是一大堆效果不佳的代码（abc 没有达到我们期望的效果），最好将其删除。（这已经是一个 TODO 事项好几年了。）

总体思路是从移除这些各种“xxxVD”抽象类开始，并使用单个卷驱动程序类，而不是所有这些带有 abc 的子类。

一般观察

  • 可能分一个或几个周期完成
  • 肯定会影响树外驱动程序，需要公开这个信息
  • 也许保留这些类，但移除 abc 并使其成为无操作类
  • 将树内驱动程序更改为仅从基础驱动程序类继承，而不是该类逗号 xxxVD 逗号 yyyVD

我们有两组描述驱动程序接口的类

  • cinder.volume.driver 中的 abc 类
  • cinder.interface 中的类

最好有一个单一的接口类源，定义实现驱动程序需要做什么。

结论

  • 这似乎在概念上并不困难，但会涉及很多代码。
  • e0ne 有兴趣看到这件事发生
  • 需要在开始之前更清楚地确定“一般观察”中的要点，但社区的总体感觉是这是一个好主意

备份驱动程序问题

由 Shatadru 领导的讨论

好吧，只有一个问题。这个问题是备份驱动程序的容器参数。它取决于你使用的驱动程序，处理方式不同

  • swift 创建一个 bucket
  • nfs 创建一个目录
  • ceph 将其用作 pool 名称


对于 Ceph 来说，如果 pool 不存在，备份最终会失败，这可能会让用户感到困惑

  • 他们期望它像其他驱动程序一样工作，你可以使用它来组织你的备份
  • 没有文档说明对于 Ceph，你需要提供一个现有的 pool 名称，否则你的请求将失败


大多数使用 Ceph 的操作员可能不希望最终用户使用它，因为他们可能已经为备份预留了一个特定的 pool，并且不希望用户将备份放在其他 pool 中。他们可能也不希望用户知道任何 pool 名称。

希望为 Ceph 驱动程序添加一个配置设置，以忽略传递的容器（如果传递了的话）。问题是，这对于其他后端驱动程序来说没有太大意义，所以我们不希望将其设置为全局设置——这意味着我们无法在 API 层检测和拒绝它。

这对于 Ceph 来说是一个真正的问题，因为最终用户可以探测以找出他们可以访问哪些 pool，并且他们可以将东西放入“错误的”pool 中。但对于其他驱动程序来说，这似乎完全没问题。

结论

  • 应该为 Ceph 驱动程序添加一个配置选项，例如“ignore_container”，然后配置的备份 pool 即使用户指定了其他内容也会被使用
  • 我们将跟踪这个问题作为一个 Launchpad bug：https://bugs.launchpad.net/cinder/+bug/1881934
  • 行动 - Shatadru - 将发布一个文档补丁
  • 行动 - rosmaita - 将更新 bug，指向修复的方向，并包含本次讨论的内容

回溯 'supported' 状态

我们在 Ussuri 中允许了这一点，在 https://review.opendev.org/#/c/700775/ 但这可能是一个疏忽。但后来我们在 https://review.opendev.org/#/c/718758/ 中又做了同样的事情，因为已经形成了先例。只想确认我们认为这是一个好主意。

结论

  • 这样做是可以的，但我们只会允许回溯到最新的稳定分支
  • 需要看到证据表明该驱动程序实际上可以在该稳定分支中正确运行（因为大多数第三方 CI 仅测试 master）
  • 行动 - rosmaita - 更新驱动程序策略，明确说明上述内容

保留 'unsupported' 驱动程序在树中

我们在 2020 年 1 月更改了我们的下一周期移除策略，以更长时间地保留驱动程序，以便为希望使用该驱动程序的操作员提供便利，同时也希望供应商最终承担责任，使其再次“受支持”。事实上，这在 Ussuri 期间发生了，几个在 Train 中未能满足 CI 必须运行 Python 3 要求的驱动程序在 Ussuri 中修复了它们的 CI，并且它们的驱动程序再次标记为“受支持”。

然而，我们遇到一个问题，导致一些审查者表达了第二想法，即 cinder 功能需要更改一些驱动程序，包括至少一个“不受支持”的驱动程序：https://review.opendev.org/#/c/720722/

因此，本次讨论的目的是确保人们同意保留树中的“不受支持”的驱动程序，即使这意味着 cinder 团队（而不是特定的驱动程序维护者）可能需要对驱动程序进行更改以支持通用的 cinder 功能。

结论

  • 我们已经知道我们需要让“不受支持”的驱动程序通过测试，这意味着 cinder 团队（而不是特定的驱动程序维护者）可能需要更改驱动程序代码；添加代码以支持 cinder 功能似乎没有太大区别
  • 当前策略是，如果维护变得负担，我们可以删除“不受支持”的驱动程序，因此我们将继续根据具体情况进行评估
    • 具体情况的原因是，在上述讨论的案例中，一些不受支持的驱动程序被修复，因为它们继承自一个被修复的类，而至少有一个不受支持的驱动程序需要自己的更改。如果更改很复杂，那么保留前者并删除后者是有意义的。
  • 行动 - 看起来这已经包含在当前策略中，所以不需要对此采取任何行动

Ussuri 开发周期回顾 - 驱动程序开发者

我们没有收到很多反馈。

损坏的 RBD 实时迁移

这实际上不是一个讨论，有人在 etherpad 上留下了一个问题，Gorka 回答了它。有关详细信息，请参阅 etherpad：https://etherpad.opendev.org/p/victoria-ptg-cinder

周四 04 月 04 日：Cinder 改进

录像

最近的安全问题

对 OSSN-0086 的快速讨论，该问题昨天宣布。我们上一个周期也有类似的问题，在 OSSN-0085 中描述了它。

结论

  • 驱动程序维护者最好查看这些 OSSN，并确保他们的驱动程序没有受到类似问题的威胁。

审查我们的审查策略

由 eharney 领导的讨论

Eric 提醒团队注意 'tox -e cover' 以及你可以使用它来确保你正在审查的代码正在被测试。这帮助他发现了一些代码的问题，这些代码看起来正在被测试，但实际上并没有。

这引发了关于在模拟时使用 spec 或 autospec 的讨论；如果没有其中任何一个，mock 会允许你在模拟对象上调用不存在的函数而不抱怨，这就是这里的问题：它允许对 .has_calls() 的调用看起来像在做一些事情，而实际上并没有（正确的方法是 .assert_has_calls()，这将使测试（正确地）失败）。

还有一些关于 pylint 任务的讨论，它总是失败；如果它只运行当前补丁中的更改，那会很好，这样你就可以知道失败是否是由你正在审查的补丁引起的。

结论

  • 最好在审查中直接显示覆盖率结果；我们可以在 Victoria 中添加一个非投票覆盖率任务，并在下一个 PTG 中重新审视，看看人们是否觉得它有用
  • 行动 - rosmaita - 设置 ^^ 的任务
  • 我们应该使“TestCase”中的“patch”和“mock_object”方法使用“autospec=True”（但如果你现在这样做，你会得到 77 个单元测试失败）
  • 行动 - ^^
  • 需要重新审视 pylint 任务，因为它能够检测问题，但目前的状态下它用处不大
  • 行动 - ^^
  • 一些团队已经实施了带有阈值的 before-and-after 覆盖率测试（这样你就不会允许降低覆盖率的更改）
  • 行动 - ^^
  • 归根结底，这些静态分析任务不会增加完成当前的 zuul “check”所需的时间，所以值得一试

Interop WG 中场休息

这是来自互操作性工作组的提醒，以确保他们了解 Cinder 的最新情况。（我们在此期间没有进行任何主要的 REST API 更改，所以我们可能没问题）。最近的更改从互操作性测试中删除了 Block Storage API v2，这很好，因为 v2 API 在 Pike 中已被弃用。

结论

  • 目前仍然有一个 Interop WG Cinder 项目联络员职位空缺！
  • 行动 - rosmaita - 验证被删除的 v2 测试覆盖的功能是否仍然被当前的 v3 测试覆盖

查看类型注解

由 eharney 领导的讨论

Eric 讨论了使用类型注解，这是 Python 3 语言的一部分，以帮助改进代码，通过允许静态检查参数和返回类型。

他有一个补丁来引入一个 'mypy' tox 环境，它将执行 mypy 类型检查，以检查 cinder 代码：https://review.opendev.org/#/c/733620/

参考文献

出现的问题是，使用这些代码将不能直接回溯到仍然支持 Python 2.7 的稳定分支，以及我们关于不在驱动程序使用的部分中使用仅限 Python 3 的语言功能的策略。共识是应该使用 Python 3。一些回溯可能会更复杂，但这就是现状。

结论

Cinderclient CLI 可用性问题

讨论由 rosmaita 领导

许多 Block Storage API 请求返回一个 202（已接受）响应。这并没有真正告诉你你的请求是否成功，而且最终用户并不总是理解这一点。

我们可以做的一件事是增强 202 响应，以便为用户提供有关下一步该怎么做的提示。在 cinderclient 中，我们可以将 --poll 选项添加到更多命令中。

出现的问题是，也许我们不应该增强 cinderclient，而是应该将其放入 openstackclient。这导致了……

OpenStack Client 旁白

因为我们正在谈论对 cinderclient 进行工作，所以出现了一个问题：openstackclient 怎么样？由于 Jay 在 TC 中，并且 TC 正在考虑统一客户端问题，我们对此进行了一些讨论，以便他可以将我们的意见带回 TC。以下是一些要点；有关更多信息，请参阅 etherpad。

  • 目前 openstackclient 和 cinderclient 之间存在功能差距。我们不能仅仅停止对 cinderclient 的工作，而是将新命令放入 openstackclient，因为用户仍然需要使用 cinderclient 来获取“差距”功能，这些功能在 openstackclient 中不存在。在停止对 cinderclient 的工作之前，openstackclient 必须与 cinderclient 具有功能奇偶校验。
  • 人们希望立即访问新功能，而不是下一个周期或再下一个周期。虽然拥有统一的客户端会很好，但当面临选择在不具备所有功能的 CLI 的便利性和为了使用新功能而必须使用不同的 cinder 客户端的不便性时，新功能将胜出。
  • osc、openstack sdk 和 shade 被宣传为“有偏见”的工具。虽然这可能对某些用户来说是合适的，但至少操作员希望完全访问 API 提供的所有内容。因此，在明确这些工具的设计理念之前，转向 openstackclient 没有意义。

结论

  • 目前，停止使用 python-cinderclient 没有意义。
  • 回到会话主题，看起来为其他资源实现 --poll 并不困难。

社区目标

由 Jay Bryant 领导的讨论。

到目前为止，Victoria 已经批准了一个目标：tosky 将所有 CI 作业移动到 native zuul v3 作业。从 cinder 的角度来看，这是好事，因为 tosky 已经将我们的大部分作业转换为 v3。

第二个可能的目标是将所有 CI/CD 作业移动到 Ubuntu 20.04（Focal）：https://review.opendev.org/#/c/731213/

对于 W 周期，https://etherpad.opendev.org/p/YVR-v-series-goals 上的目标都是候选目标。一个早期热门是删除 rootwrap。有人在谈论 openstackcli，但这可能需要更多讨论（参见之前的会话）。

Ussuri 开发周期回顾

对此没有收到很多反馈。一个出现的问题是，虽然我们可能无法加快审查速度，但我们可以使审查更具可预测性。


（我们提前结束，参加虚拟欢乐时光，未录制。）

2020 年 6 月 5 日星期五：XP & TCB（跨项目和处理事务）

录像

Cinder/Glance 使用 Ceph 从卷创建镜像

由 abhishekk 领导的讨论

当 Glance 在创建镜像时不知道镜像的大小，并且使用 Ceph 后端时，会因为其保守的行为而导致 thrashing，它会发出非常小的调整大小请求，因为镜像正在写入。在上海峰会上，我们讨论了两种解决方案：（1）在请求中传递大小（由于 Cinder 已经知道卷需要多大；image API 变更）或（2）进行 glance_store 变更（发出更大的调整大小请求（例如 1GB）并在最后缩小）。在上海，Cinder 团队对方案 (2) 感到满意。Glance 团队没有时间在 Ussuri 中实现此方案，并希望确保我们仍然对该方案感到满意。我们是。

使 cinder 存储与 glance 兼容多种存储

由 abhishekk 领导的讨论

Glance 现在能够为用户提供不同的后端镜像存储。一种用例是让操作员提供不同的层级，这些层级以 store_id 和描述呈现给用户（例如，'bronze'：'适合任何用途的低成本存储'；操作员不需要向最终用户暴露后端技术，只需告知用户有不同的存储可用即可）。如果操作员正在使用 cinder glance_store 驱动程序，当前只能为该存储配置一个 volume_type 用于使用，即使 Cinder 中定义了多个由各种 volume_type 定义的存储层级。

看起来一种解决方法是继续使用单个 cinder glance_store，但赋予它在发出 volume-create 请求时传递不同 volume_type 的能力。volume_type 不会直接暴露给最终用户——相反，每个 volume_type 可以与 glance stores-info 响应中的 store_id 相关联，以便不会破坏存储抽象层。

glance cinder 存储的门禁作业

讨论由 whoami-rajat 领导

Rajat 说

目前我们支持 glance 中的 cinder 存储，但没有门禁作业来验证当 glance 收到请求时，镜像的创建/删除是否按预期工作。我一直在 glance_store 的 cinder 上进行门禁作业[1]（最终通过了），但我认为在 glance 门禁上有一个作业来测试当 glance 收到请求时整个镜像创建流程会更有意义。

[1] https://review.opendev.org/#/c/329825/

结论

  • cinder glance_store 的使用量似乎在增加；Cinder 和 Glance 团队都同意确保对其进行充分测试会很好。

Glance 镜像协同定位

jokke_ 主导讨论

在 Ussuri 中，Cinder 实现了一个方案来协助 Glance 进行镜像协同定位。这意味着如果一个卷是从镜像创建的，如果该卷后来被上传为镜像，Cinder 会传递原始镜像的 image_id，以便 Glance 可以确定原始镜像位于哪个存储中，并将新镜像的副本放在相同的位置。Glance 团队希望修改 Cinder 侧的实现，以便不要将 base_image_ref 作为 image-create 调用中的 header 传递给 glance，而是如果存在 base_image_ref，Cinder 将调用 glance Import API。这将使 Glance 能够重用经过更好测试且更易于维护的代码路径。

结论

  • 该提议似乎是合理的。它不应该使 Cinder 侧的 image-create 耗时更长；Import API 返回 202（已接受）并异步执行其工作，因此它只是一个快速的 API 调用。不过，我们需要更仔细地查看。

刷新 connection_info

eharney 主导讨论（lyarwood 无法到场）

我们简要讨论了 Lee 在 ML 和评论中概述的提议


这似乎是合理的。Gorka 提到有一个邮件线程，他在其中更详细地讨论了这方面的一些内容。

结论

  • lyarwood 回来后跟进将其放入规范
  • 挖掘 Gorka 的邮件线程，以确保解决这些问题

DR 操作和中断的卷连接

sfernand 提出的相关主题

灾难恢复操作会在虚拟机中留下中断的卷连接。也许让 Nova 在故障转移/故障恢复后自动重新建立 iscsi 连接会很有用？

  • 如果启用了多路径，也许可以这样做……但不会容易
  • Fernando 有兴趣从事这项工作……Gorka 自愿与他讨论这个问题，并在适当的时候请 Lee 加入，因为他对这个问题也很熟悉
  • 工作项目
    • Cinder 驱动程序必须报告它们是异步还是同步，A/A（无需执行任何操作，因为多路径已经可以访问两个路径）或 A/P（我们需要刷新连接）复制
    • Cinder 必须告知 Nova 哪些卷具有新的“源”，或者自动更新初始化的连接并告知 Nova 刷新特定实例
    • OS-Brick 能够尽可能干净地从旧连接切换到新连接

动态前端 QoS

我们有能力在 Cinder 中指定前端 QoS，这些 QoS 在卷附加时由 Nova 应用。一直有要求提供一项功能，允许在卷附加时更改这些 QoS。当 Cinder 中的 QoS 规范发生更改时，或者当卷扩展并且使用 iops_per_gb QoS 规范时，这将很有用。

这将需要

结论

  • 大家普遍认为这是一个好主意，但没有在场的人表示有兴趣接手。

Victoria 规范审查

我们快速浏览了当前提出的规范：https://review.opendev.org/#/q/project:openstack/cinder-specs+status:open

请参阅 etherpad 以获取评论。

技术债务

Alembic！

我们需要在本周期完成它。Rosmaita 将从事这项工作，并根据需要招募人员。

Block Storage API v2 移除

它自 Pike 以来已被弃用。我们至少应该移除面向外部的内容。（内部，v3 API 使用与 v2 贡献的扩展相同的代码。）

其他事项

Ussuri PTG 中有一些未完成的项目仍然可行：https://etherpad.opendev.org/p/cinder-ussuri-ptg-actions

周期优先级和时间表

时间表

补丁：https://review.opendev.org/#/c/733730/

这个周期比较短——规范冻结在 R-15，就像在 ussuri 中一样，但它似乎提前大约 3 周发生。所以请务必在日历上标记日期。

我注意到了可能在重要截止日期前后发生的假期

  • 我们将会在规范冻结的时候审查人员不足，所以本周期的冻结将在星期三进行（而不是通常的星期五）。请在处理规范修订时记住这一点。
  • 我们还会在功能冻结前周末审查人员不足；有一个假期，但考虑到疫情情况（希望到时候正在缓解），人们可能会倾向于多休一天来延长周末。因此，最后一刻的审查可能无法获得。


为了避免在 Ussuri 功能冻结之前发生的大量驱动程序功能审查，时间表上有一个新的截止日期：Cinder 驱动程序功能声明。这将帮助我们更好地组织审查。有关详细信息，请参阅时间表上的描述，如果您有任何问题，请问我。

优先级

(此列表可能会修订，但应该在 6 月 19 日之前基本确定)

我们有一些在 Ussuri 中开始的未完成的项目，我们希望在 Victoria 中尽早完成（目标是 milestone-1，但它来得非常快）

  • volume-local-cache
  • nfs-volume-encryption
  • os-brick 更改以支持飞行中的镜像加密/解密


有两个弃用需要解决

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