跳转到： 导航, 搜索

CinderXenaMidCycleSummary

简介

在 Xena 虚拟 PTG 上，我们决定继续采用举行两次中期会议的做法，每次会议时长两个小时，分别在 R-18 和 R-9 周进行。

以下是讨论的简要总结。完整细节请参见 etherpad：https://etherpad.opendev.org/p/cinder-xena-mid-cycles

第一次会议：R-18：2021年6月2日

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

Cinder 项目通用事务

快速讨论以下问题

  • 提醒大家我们现在在 OFTC 上使用 #openstack-cinder 和 #openstack-meeting-alt。旧的 Freenode cinder 房间里有 69 个人，但没有人说话，所以看起来大家已经完成了过渡。
  • TC 要求团队考虑在他们的项目频道中举行团队会议，而不是使用专用的 #openstack-meeting* 房间。听起来大多数人对此表示同意或没有意见。由于我们已经有一个需要大家注意的变化（我们的下一次会议将在 OFTC 中举行），因此我们现在将继续在 #openstack-meeting-alt 中举行会议，并在下一次会议或之后投票决定是否迁移。
  • 发布团队希望确保库在周期早期发布，以便自最近的稳定分支被切分以来积累的变化可以得到锻炼，并且我们可以找出是否破坏了任何人的使用。我们快速审查了未合并的 os-brick 补丁，并选择了两个应该包含在此早期发布中的补丁。Rajat 会在更改合并后更新发布补丁。（我们将等待删除 v2 支持后的 python-cinderclient 早期发布；见下文。）
  • 有人提出了一个关于 stable/queens 的 backport 的问题：https://review.opendev.org/c/openstack/cinder/+/760362。问题是它是一个相当大的补丁（大约 1K 行，其中一半是单元测试），并且它不是从 rocky 的干净 backport（因此需要更仔细地审查）。另一方面，该更改仅限于单个驱动程序。普遍的看法是，由于我们已经允许从 victoria（它被引入的地方）backport 到 rocky，因此我们应该保持一致，并允许将其 backport 到 queens。此外，这是一个重要的错误修复，而且人们仍在使用的 queens。
  • 事实证明，os-brick 没有标记 'vulnerability:managed'，这让我感到惊讶。团队的问题是：有人记得这是有意为之吗，或者只是一个疏忽（因为大多数人直接针对 cinder 报告安全漏洞）？没有人认为这是有意为之，并且团队同意，由 VMT 管理 os-brick 的私有安全漏洞是有意义的，就像目前 cinder 和 cinderclient 一样。
  • 由 os-brick 提出的补丁引发了关于 cinder 项目仓库中 tox.ini 中默认 envlist 的讨论：https://review.opendev.org/c/openstack/os-brick/+/793221。我们在这方面并不一致，尽管在某种程度上这无关紧要，因为在场的人都承认从未在本地运行测试时使用默认的 tox 环境。默认环境旨在为新贡献者服务，普遍的共识是，我们希望他们运行 (a) 使用我们支持的最新 python 版本进行单元测试，以及 (b) pep8。

Block Storage API v2 移除更新

已经发布了 cinder 和 cinderclient 的补丁，但它们没有得到很多审查。因此，我们将采取采用补丁策略，以便人们对审查特定补丁负责。对于每个补丁，我们需要两个核心审查员（像往常一样），并且最好再有一个审查员（不必是核心）进行合理性检查，因为大多数补丁都很大。

关于 enable_v3_api 选项怎么办？

我们讨论了如何处理 cinder enable_v3_api 选项。请参阅


一些选项是

  1. 在 Xena 中弃用，并在 Y 中移除；并在 Xena 中尊重它。这意味着如果它已启用，在运行 cinder-api 的节点上可用的唯一 Block Storage API 调用将是 /versions 请求，该请求将返回一个空的可用的版本列表。不确定这有什么用处。（这是当前补丁中完成的。）
  2. 在 Xena 中弃用，并在 Y 中移除，但在 Xena 中忽略它（也就是说，即使 cinder.conf 中实际设置为 false，也表现得好像 enable_v3_api=true 一样）。
  3. 直接在 Xena 中将其移除，因为如果被忽略，就没有理由存在了。另一方面，选项 2 会记录一个弃用消息，该消息可以解释该选项现在是一个空操作，因此对于没有仔细阅读发布说明的人来说，将会有日志消息可用。


我们决定再考虑一下，并在后续补丁中处理它。

cgroupv1 -> cgroupv2 更新

PTG 的后续行动：libcgroup v2.0，支持 cgroup v2，并提供 cinder 使用的 'cgexec' 于 2021 年 5 月 6 日发布。这将允许我们使用当前代码进行最少的更改。但是，它不会在一些发行版中打包，因此我们需要切换到 Plan B。

另一种选择是使用 systemd，我们将定义 drop-in slice 文件来设置 io 限制，然后使用 systemd-run 运行当前使用 libcgroup 的 cgexec 运行的复制/转换命令。Eric 指出，我们可以让 cinder 按需生成文件，就像我们在代码的其他地方所做的那样。这样，我们可以继续使用设置 io 限制值的配置选项，从而保留与当前配置文件向后的兼容性。

仅供参考，以下是当前代码中处理限制的位置

Xena 规格评审

（注意：即使 R-18 中期会议的时间安排是为了让规格提案者在 R-15 结束前的规格冻结之前获得反馈，但消息显然没有传开，我们需要找到更好的沟通方式，既要让提案者知道要参加中期会议，又要让他们意识到，如果当前的时间阻止了参加，他们应该在周期早期参与中期会议安排过程。）

以下是我们讨论的规格摘要。任何没有讨论的规格提案，并且需要比 Gerrit 审查中更多的反馈，都应该联系 Cinder 团队寻求帮助（在每周会议议程中提出主题，在 OFTC #openstack-cinder 频道中询问，或通过 openstack-discuss 邮件列表）。

另外，这里是中期会议录像的链接，以便为以下摘要提供更多上下文：https://www.youtube.com/watch?v=bSs5AHz2Iq8

更新原始卷的可用区

规格提案：https://review.opendev.org/c/openstack/cinder-specs/+/778437

  • 团队普遍支持这个想法，但我们需要更多细节。
  • 这个规格可以采用更准确的标题，因为它更像是“将与后端相关的所有内容迁移到新的可用区，当后端已移动到新的 AZ 时”，这让读者更好地了解了所解决问题的复杂性。
  • 问题是关于正在使用的卷怎么办？这只适用于可用的卷吗？操作员在运行此 cinder-manage 操作之前需要采取哪些步骤？
  • 我们需要清楚地描述如何处理其他与 AZ 感知的资源，例如
    • 快照
    • 备份
    • 组
  • 需要添加一个文档说明，操作员需要更新包含可用区的任何 volume_types。

支持将任何快照还原到卷

规格提案：https://review.opendev.org/c/openstack/cinder-specs/+/736111

  • 团队仍然支持这个想法，但继续强调我们需要一个更彻底的提案，特别是关于
    • 供应商需要了解此功能的含义，特别是对于删除
    • 提供一个 tempest 测试场景的概述将非常有帮助，因为它将清楚地说明各种应用此操作的预期先决条件和后置条件
      • 必须清楚的是，添加此操作后，所有正常的 Cinder API 语义都应该得到尊重
      • cinder-tempest-plugin 中的一套测试（可以从概述中实现）将帮助驱动程序维护者评估此更改对其驱动程序的影响
  • 关于 'safe_revert_middle_snapshot' 属性出现了一个问题。它是可以为每个驱动程序定义的静态属性，还是取决于其他因素（例如，许可、后端 API 版本等），这些因素必须由驱动程序动态确定？
  • 请清楚地解释以下情况会发生什么：
    • volume -> snap A -> snap B -> snap C
    • 将卷还原到 snap B，然后将数据写入卷
    • 这会对 snap C 有什么影响？
  • 所有正常的 cinder API 语义都应该仍然有效。例如，
    • 如果您将卷 v1 还原到 A，您仍然应该能够删除 A
    • 如果您将卷 v2 还原到 A，您应该拥有来自 A 的原始数据（也就是说，它不应该包含 v1 在其还原之后所做的任何更改）

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

规格提案：https://review.opendev.org/c/openstack/cinder-specs/+/766130

  • 一个关键问题是：旧的副本会发生什么？
  • 需要一些文档来告知操作员他们需要向供应商询问哪些关于其特定后端的具体问题。例如，如果复制是异步的，那么在迁移的卷在一段时间内未复制的情况下，就会存在一个时间段。可能还有其他您能想到的问题。
  • 规范的末尾有一条评论：“我们可以遵循 multiattach 实现此规范提案”。您能否解释 multiattach 如何帮助您的实现？我们不清楚您在这里的想法是什么，解释将帮助我们更好地理解您的提案。

第二次会议：R-9：2021年8月4日

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

快照状态重置的健壮性

问题在于需要考虑的状态转换非常多，看起来难以全部考虑到。那么该怎么办？

Eric 提到，另一种方法是从 REST API 中移除此功能，并使其仅通过 cinder-manage 访问，这样可能只有了解其影响的人才会使用它。但问题在于，你必须访问 cinder 节点才能运行 cinder-manage，这意味着只有顶层支持人员才能访问它，这可能不是我们想要的。

建议选择一个小的、明确的案例（例如，spec 中的 2），并至少以此开始实施。此外，有些目标状态（特别是以“-ing”结尾的）绝不应该转移到，因此我们也可以阻止这些状态。（这些状态由 cinder 用于标记工作流程的中间过程，你不希望允许某人通过简单地更改数据库中的状态来假装将卷置于所需工作流程的中间过程，因为这样做实际上不会有任何作用。）

行动

TusharTgite：按照上述讨论的思路进行实施

如何处理 enable_v3_api 选项？

这是 xena R-18 中期周期会议的后续讨论，讨论记录在此：https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#what_about_the_enable_v3_api_option.3F 向 TC 在邮件列表中询问了这个问题：http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023898.html

行动

rosmaita：提交一个移除该选项的补丁：https://review.opendev.org/c/openstack/cinder/+/803533

python-cinderclient 后续步骤

行动

rosmaita：提交一个调整配置的补丁：https://review.opendev.org/c/openstack/python-cinderclient/+/803522

os-brick Xena 发布

这很快就要来了：os-brick Xena 发布在 R-7（8 月 16 日当周）

优先级

行动

大家：请尽快评审上述两个补丁

sqlalchemy-migrate -> alembic

Stephen Finucane 提交了一堆补丁来推动这个进展。由于工作变动，他可能无法进一步提供帮助。

Luigi 指出 sqlalchemy-migrate 可能已经不受支持。我们可以提出一个 festival 来实现这一点，因为我们迫切需要它。

行动

rosmaita：组织一个围绕此问题的评审 festival 或类似活动

qcow2-v2 支持从各种 linux 发行版中移除怎么办

“移除”可能有点夸张；例如，RHEL 的提议是提供只读支持。

这并不是 cinder 的问题，因为 qcow-v3 一直是 qemu-img 自 QEMU-1.7（2013 年 12 月）以来创建 qcow2 的默认格式，因此对于从 Icehouse（2014 年春季）开始运行 openstack 的任何人来说，cinder 仅创建 qcow2-v3 镜像用于基于 remotefs 的驱动程序。

cinder 的问题是如果操作员管理 qcow2-v2 格式的镜像。

Eric 询问：cinder manage API 是否支持使用 NFS 驱动程序管理 qcow2？他怀疑我们可能没有。所以，如果没有，我们应该继续不支持它！

行动

rosmaita：调查我们是否已经不允许操作员管理 NFS 驱动程序卷，该卷是 qcow 镜像，并报告结果

keystone “trusts” 在 cinder 中的支持

这背后的背景是，有一个 etherpad 收集操作员的痛点，以评估拥有“修复你项目中的一些痛点”社区目标的可行性（也就是说，每个项目修复自己的痛点，而不是试图找到一个全 openstack 的痛点来解决）。此补丁在列表中：https://review.opendev.org/c/openstack/cinder/+/785362

仍然不清楚报告的问题是否需要 trusts。我更愿意使用服务令牌，我们已经支持了它们，并且它们更简单。

行动

rosmaita：在补丁和/或相关 bug 上留下评论，解释这一点，并询问为什么提出的方法不能通过服务令牌来实现的原因

向操作员公开后端信息

这背后的背景是，一个补丁正在使用服务对象的 'disabled_reason' 字段来解释为什么在后端禁用了复制，这似乎是对该字段的非预期使用：https://review.opendev.org/c/openstack/cinder/+/791281/5/cinder/volume/manager.py#636

GirishChilukuri 解释：在复制后端的初始化期间，由于某种原因，任何一个站点都可能宕机，并且我们将服务复制状态设置为禁用。为了向用户提供信息，我们使用 disabled_reason 来解释为什么复制被禁用。我们可以看到“disabled_reason”在故障转移期间用于更新原因，因此我们使用 disabled_reason 字段来更新复制状态。

讨论中出现的一些要点

  • 这不适合在服务上使用 disabled_reason
  • 在驱动程序中，公开此信息（特别是关于复制状态）是一个常见用例
  • 不清楚服务对象是否应该记录此信息

行动

Girish 和他的团队将提出一种公开此信息的方法，并咨询其他驱动程序开发人员（simondodsley 来自 Pure 表达了一些兴趣）

常规项目维护问题

行动

大家：阅读并采取上述行动！

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