跳转到： 导航, 搜索

CinderXenaPTGSummary

目录

简介

此页面包含在 2021 年 4 月 19 日至 23 日举行的 Xena 开发周期的项目团队会议期间讨论的主题的摘要。Cinder 项目团队从 4 月 20 日星期二到 4 月 23 日星期五举行会议，每天 3 小时（UTC 时间 1300-1600），星期五的会议持续 4 小时。

Cinder 团队在 Xena（虚拟）PTG，2021 年 4 月。


本文档旨在总结每个会议的内容。更多信息可在 cinder PTG etherpad 上找到


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

星期二 4月20日

录像

问候和一些 Cinder 项目事务

事务无特定顺序

  • 所有交付成果来自 stable/train 的最终发布是 2021 年 5 月 12 日，因此请检查是否有任何需要回溯的关键错误并立即开始处理这些错误。
  • 我们需要从 rbd-iscsi-client 进行发布，以验证所有工具是否正常工作。希望在发现需要发布的任何关键错误之前完成此操作。将 rbd-iscsi-client 作为 OpenStack 项目进行补丁格式化仍需要审查：https://review.opendev.org/c/openstack/rbd-iscsi-client/+/774748/
  • 有一补丁将 Cinder 特定的日期放在 OpenStack 发布计划上。与通常日期相比，唯一值得注意的变化是将规范冻结提前到 R-18 中周期后的 2 周。（一周的时间不足以让人们修改和重新提交，这需要大量的规范冻结例外。希望这次我们可以避免这种情况。）请检查日期并留下评论，如果发现任何问题：https://review.opendev.org/c/openstack/releases/+/786951
  • R-18 和 R-9 的两个中期周期运行良好，所以让我们再次这样做。格式为 2 小时。我建议在每周 Cinder 会议举行的那一周代替会议举行；这样，每个人都应该能够至少参加他们预留的一个小时的 Cinder 会议。时间可能为 UTC 时间 1300-1500。请检查是否有冲突
    • R-18 中期周期：6 月 2 日
    • R-9 中期周期：8 月 4 日
  • 一些需要注意的快速链接
    • Cinder 项目通用信息：tiny.cc/cinder-info
    • Cinder 组信息：tiny.cc/cinder-groups
  • 有人有兴趣帮助编写文档。我要求她从审查补丁的发布说明开始，以确保清晰、语法等。这些是用户可见的文档，因此使其正确很有帮助。
  • 我们没有安排 Wallaby 发布周期回顾的时间，也许我们可以在今天的欢乐时光进行回顾。

非管理员用户无法通过 API 确定卷是否将支持多挂载

这是讨论的背景：https://github.com/kubernetes/cloud-provider-openstack/pull/1368#issuecomment-819442191 以及后续评论。

基本思想是云端用户希望在 OpenStack 云中运行 Kubernetes。因此，Kubernetes 安装“操作员”（Kubernetes 术语，我们说的是一个程序，而不是 OpenStack 云的人工操作员）为最终用户使用正常的 OpenStack 项目凭据（而不是管理员）。对于此特定问题，Kubernetes 安装程序希望允许多挂载块设备，如果该云中的底层 Cinder 支持它。 （它通过查看可用于最终用户的卷类型并为每个卷类型创建一个 Kubernetes 存储类来执行此操作。）多挂载信息位于仅对管理员可见的卷类型 extra-specs 中（因为它们可能包含有关部署的后端特定信息，不应向最终用户公开）。因此，目前安装程序确定是否支持多挂载的唯一方法是为每个可用的卷类型创建一个卷并检查生成的卷是否为多挂载。这并非最佳选择（有人可能会说既耗时又愚蠢）。

在 Cinder 的历史上，暴露非敏感 extra-specs 信息给最终用户的问题已经出现过，建议要么适当地命名卷类型（例如，“具有多挂载的 Gold 级别”）要么将此信息包含在卷类型描述中。但这因云而异，不适合机器使用。拥有标准字段在卷类型-show 响应中会更好。

在讨论过程中出现了一些问题

  • 我们应该提供一些明确的文档。例如，如果您有一个可以匹配多个后端的卷类型，那么构建的卷是否为多挂载将取决于 (a) 卷类型是否支持多挂载，以及 (b) 调度器将卷放在也支持多挂载的后端上（这也取决于：(c) 您如何配置调度器）。因此，为了支持此用例（或者，实际上，任何最终用户想要知道卷是否为多挂载而无需先构建卷的用例），Cinder 管理员需要确保支持多挂载的卷类型与也支持它的后端相关联（并且调度器配置正确）。
    • 但是如果后端空间不足怎么办？好吧，没关系，最终用户将无法在其中创建卷。但这似乎比获得没有所需属性的卷要好。
    • 这没有在讨论中提出，但看起来存在通用卷类型（例如，可以多挂载，但可能不是，但只要某个后端有空间，您就会获得一个卷）和非常具体的类型（例如，只有多挂载 <is> True extra spec 如果映射到该类型的后端都支持多挂载）之间的张力。如果我们只是要暴露多挂载 extra spec，那么 Cinder 管理员就不能拥有一个通用的类型，在可用时支持多挂载，因为这不符合我们正在讨论的 Kubernetes 用例。现在也许这没什么大不了的，因为对于多挂载，似乎如果您希望您的工作负载具有多挂载，您真的希望它，因此拥有一个有时没有多挂载卷的多挂载卷类型有点毫无意义。但我不知道这是否适用于其他非敏感 extra-specs。我的意思是，我怀疑我们想要引入 volume-type-metadata，Cinder 管理员可以暴露管理员认为适合最终用户的信息。缺点是管理员需要在 extra-specs 和 volume-type-metadata 中两次配置信息，但它也可以让为特定消费者定义键/值成为可能（例如，“k8s:supports_multiattach”: “true”（这些必须是字符串值），“k8s:whatever”: “something”，甚至指示卷类型是否应由 Kubernetes 使用的元数据）。优点是键/值可以由 Kubernetes-Cinder-CSI 操作员定义，而不是 Cinder。
  • Manila 目前向最终用户公开一组后端功能，同时保持其他功能保密：https://docs.openstack.org/manila/latest/admin/capabilities_and_extra_specs.html
  • 这与 Eric 在丹佛 PTG 上讨论的并提出了初始规范的功能报告相关：https://review.opendev.org/c/openstack/cinder-specs/+/655939
    • 基本思想是，虽然定义了功能报告（并在某些驱动程序中实现），但它不够具体，无法帮助操作员编写 extra-specs（例如，supports_qos: True 无法帮助您编写后端的 qos extra-specs（虽然它会告诉您查看驱动程序文档或代码以了解该怎么做））
    • 实施此功能不会直接帮助 Kubernetes 用例（因为此功能 API 不会向最终用户公开），但定义它可以在识别适合向最终用户公开的后端功能（或至少开发合适的词汇）的努力中有所帮助
  • Walt 指出我们当前在 volume-show 响应中向 Cinder 管理员公开一些 volume-admin-metadata，因此这可以作为我们在此处的操作模型，在 volume-type-show 响应中向最终用户公开选定的 extra-specs
  • 可能最好添加一个 API 来询问哪些卷类型支持最终用户感兴趣的功能
  • 有用的功能可以公开
    • 多挂载
    • 可用区
    • 卷复制
    • 在线扩展功能
    • QoS
    • 可能希望使其可配置（类似于 resource_filters），以便 Cinder 管理员可以决定公开什么？
  • 这对 Horizon 或其他 UI 来说将很有用——例如，不要让最终用户尝试扩展不支持的卷类型的已挂载卷

结论

  • 这将是对 Cinder 的一个很好的补充
  • 对于 OpenShift/Kubernetes 用例，以标准格式向非管理员用户公开一些 extra-specs 就足够了。
  • Matt Booth 和 Tom Barron 将起草规范
  • Cinder 团队将审查并帮助推动规范的进展
  • Eric 将复活他的功能 API 规范；团队普遍支持它

互操作性工作组

互操作性工作组所做的一部分是确定云端运营商可以运行的一组测试，以证明工作负载在 OpenStack 云中的可移植性。通过测试的供应商可以使用 OpenStack 徽标。目前，这些是 interop git 仓库中定义的特定子集 tempest 测试。

最新：https://opendev.org/osf/interop/src/branch/master/2020.11.json

想法是测试涵盖两个版本向后和向前一个版本。因此，2020.11 指南涵盖 ussuri 和 victoria 以及 wallaby。

您可以拥有“必需”或“建议”功能。要允许供应商使用徽标，必须通过“必需”功能的测试。在成为必需功能之前，功能必须是“建议”功能至少一个周期。

Interop WG 对 Cinder 在 Wallaby 中新增的功能很感兴趣，希望将其纳入咨询能力范围。他们关注的是任何可能影响工作负载可移植性的功能。

如果我们确定了这些功能，我们可以为它们编写 tempest 测试，然后将其提交给 Interop WG，以纳入咨询能力范围。具体流程是，厂商使用 refstack 在其云环境中运行测试。Refstack 允许直接向基金会提交结果。这样，Interop WG 就可以获取有关咨询能力的数据（例如，如果这些能力未在 OpenStack 云中公开，那么它们可能不适合成为“必需”功能）。

结论

  • 目前的 tempest 测试最多覆盖 3.0 微版本。
  • 后续的许多微版本使块存储 API 更加用户友好，但可能不会影响工作负载可移植性。
  • Cinder 团队：将审查 3.0 到 3.64 之间的微版本变更，以查看是否应添加任何“咨询”测试
  • Arkady：将跟进 Cinder 团队

Wallaby 周期回顾

我们显然存在审查带宽问题，需要开始寻找新的核心成员来帮助我们。

目前正在使用 Cinder 并且感兴趣的人员应联系 PTL (rosmaita) 或任何 当前核心成员，以获取有关 Cinder 方面我们希望看到的内容以及如何与管理层沟通以获得足够的时间投入到该项目的指导。

Gorka 询问我们是否可以拥有在特定领域具有专业知识的“专家”核心成员。实际上，我们已经有了先例，即卷驱动程序。Lucio（不幸的是，他换了工作）做了一批高质量的驱动程序审查，核心团队同意，虽然他还不熟悉所有的 Cinder，但他可以继续发展这方面的知识，并且只 +2 他确信的补丁。这使我们能够在不牺牲审查质量的情况下增加审查带宽。

因此，重点是，不要觉得你必须了解所有的 Cinder 才能考虑成为核心成员。同样，当前的核心成员在寻找候选人时也应牢记这一点。

结论

  • 当前的核心成员应留意可能有所帮助的人员。由于这涉及人事问题，我想保持一定的保密性，因此请仅向当前核心成员发送电子邮件（即，不要发送到邮件列表），以便我们可以在内部讨论，并且 PTL 可以直接与候选人联系，提供建设性的反馈。当然，当我们确定某人为认真的核心成员候选人时，我们将在邮件列表中公开进行通常的投票。
  • 给核心成员候选人的建议
    • 不要在补丁上留下 +1 或 -1 而不加评论……说明你查看了补丁的哪些部分。如果代码看起来不错，请检查单元测试。如果它们也看起来不错，请检查测试覆盖率报告。如果是一个驱动程序，请检查第三方 CI 结果。你可能找不到任何负面内容，这是完全可以的，但留下一些表明补丁好的内容，而不仅仅是你的 +1
    • 查看核心审查员留下的 -1，以了解他们在审查补丁时关注的问题类型

2021 年 4 月 21 日星期三

录像

移除块存储 API v2

块存储 API v2 在 Pike 中已被弃用，并且已经符合移除条件一段时间了。它没有在 Wallaby 中移除，从中吸取的教训是，必须在 Milestone-1 之前将其移除，否则就不会发生。

Xena Milestone-1 是 R-19 周（5 月 24 日那周），大约还有 1 个月的时间。

我们有两个交付成果受到此影响：python-cinderclient 和 cinder 本身。

python-cinderclient

我们于 2020 年秋季通过一系列电子邮件向 ML 提出了从 cinderclient 中移除 v2 支持的建议

没有提出任何反对意见，所以我们应该没问题。

这将通过一系列补丁完成

  1. 有一个客户端类可以让你获得 v2 或 v3 客户端；将此更改为仅返回 v3 客户端
  2. 完全删除 v2 客户端类并修改测试
  3. 删除仅导入 v3 类的 v2 类并修改测试
  4. 对于简单导入 v2 类的任何 v3 类，将 v2 类移动到 v3 并修改任何受影响的测试
  5. 对于任何剩余的 v2 类，将模块名称中的“v2”替换为“internal”（或其他表明它们不应由消费者直接使用的名称），并修改测试

cinder

与专门设计为由消费者作为块存储 API v2 的 python 语言绑定使用的 cinderclient v2 类不同，cinder v2 类不打算暴露给消费者。因此，删除/重命名这些类并不重要（至少现在是这样），所以我们可以直接将它们保留原样。（这也会使回溯更容易。）

那么，对于 cinder，我们需要做的是

  1. 不再返回 v2 作为版本选项
  2. 当请求 v2 API 时返回 404（或者我们当前对 v1 所做的事情）
  3. 更新测试
  4. api-ref 的 v2 部分需要删除
  5. 文档更新以删除 v2 引用

其他团队

对其他团队的影响

  • osc/sdk
    • osc 有代码会通过尝试从可用的 cinderclient 中导入来检查 cinderclient v1；可以发布一个补丁，对 v2 进行相同的检查
    • openstacksdk 目前仅支持 v2 和 v3；它是分支的，因此可以从 xena 开发分支中删除 v2（看起来 v3 类对 v2 类没有依赖关系）
  • keystone/devstack
    • 需要从服务目录中删除 v2 端点（可能更多的是 devstack 的事情，而不是 keystone 的事情？）
  • nova
    • 验证他们正在使用 v3（在与 nova 团队的跨项目会议期间检查；他们没有 v2 依赖关系）
  • ironic
  • triple-O
    • alan 已经删除了 v2 依赖项/支持
  • 通用
    • 向 ML 发送另一条通用公告，说明我们这次是认真的


结论

  • cinderclient：有人提出了这个问题：“由于这是一个不兼容的更改，我们如何防止仍然使用 v2 的部署在执行 pip -U 时中断？”
    • 我不知道我们能做些什么，除了向邮件列表发送消息，宣布 python-cinderclient 的第 8 版将不再支持块存储 API v2，并且如果任何人需要 v2 支持，任何脚本（或书面说明）中的“pip install -U python-cinderclient”都应替换为“pip install -U 'python-cinderclient<8.0.0'”
  • rosmaita 将很快发布 python-cinderclient 补丁
  • rosmaita 将与 enriquetaso 和 whoami-rajat（以及任何其他感兴趣的人）协调 cinder 方面的更改
  • rosmaita 将与 osc/sdk 团队联系
  • rosmaita 将与 qa 团队联系，了解 devstack
  • rosmaita 将向 ML 发送通用公告

mypy 状态和下一步

Eric 报告说，仍然有一些 cinder mypy 补丁未被审查，并且有一些新的 os-brick 补丁：https://review.opendev.org/q/(project:openstack/cinder+OR+project:openstack/os-brick)+topic:%2522mypy%2522+(status:open)

补丁堆积如山，并且它们相互依赖，因此保持它们最新状态很麻烦。我们决定进行审查节，以便每个人都可以抽出一些时间来审查它们。

Eric 提醒我们，我们现在不追求完全覆盖，我们只是试图尽可能地覆盖，并尽量减少干扰，首先关注有趣的情况。此外，这些更改不太可能影响代码的当前运行方式。

有一些未解决的问题

  • 仍然需要弄清楚如何处理 cinder oslo 版本对象
  • 需要弄清楚如何处理我们导入的没有注释的库
  • Eric 有一个补丁可以自动为我们使用的 oslo 库添加注释，但他不确定这是否是一个长期的好解决方案


结论

配额测试

Gorka 在 Wallaby 中修复了一堆长期存在的配额错误，并且有一些关于简化代码和修复更多错误的思路。最好进行一些测试，以锻炼代码并能够检测回归。

Ivan 建议我们可以使用 Rally 来测试配额，但他找不到一个好的例子来使用它来做我们想做的事情。此外，我们可能需要高并发，而 Rally 看上去不太并发。

一些可能的测试

  • 需要多个用户同时执行操作。
  • 创建/删除卷和快照
  • 可能希望从人为设置的低配额开始。
  • 不确定检查中有多少空间可以进行测试……但如果我们使用假驱动程序，那不是问题
    • Ivan 不确定假驱动程序是否仍然有效，但如果有问题，应该很容易修复
  • 管理/取消管理测试
    • 此功能必须添加到假驱动程序中，因此我们可以暂时搁置它


Gorka 提到他修复的一些错误与临时资源有关，所以也许我们可以添加代码来运行整个 tempest 运行，并验证在最后配额是否正确。Ivan 提到他不确定当前的 tempest 测试是否正确清理所有内容，并且我们希望确保我们正在测试 cinder 配额，而不是 tempest。（Gorka 后来提到 tempest 清理对于这些测试无关紧要。Cinder 负责创建/删除临时资源，因此即使“真实”资源没有被 tempest 在之后清理，如果我们的兴趣在于确保临时资源被正确计数，我们也应该没问题。）

有人询问 Keystone Unified Limits 的状态，但最近没有人研究过它。

结论

  • 从向 tempest 作业中添加配额检查开始
  • Ivan 将继续研究 Rally

修复卷驱动程序类

情况是

  • 我们有一些抽象的驱动程序类，即 BaseVD、CloneableImageVD、MigrateVD、ManageableVD 和 ManageableSnapshotsVD
  • 我们还有一个具体的驱动程序类 VolumeDriver，它继承自 ManageableVD、CloneableImageVD、ManageableSnapshotsVD、MigrateVD、BaseVD
  • 大多数树内第三方驱动程序只是从 VolumeDriver 继承
  • 此外，我们还有用于测试驱动程序是否实现所需功能的接口类

将功能分解到各种抽象 VD 类中似乎并没有太大帮助，并且让新的驱动程序实现者感到困惑。最好回到只使用 VolumeDriver。

那么，我们如何删除抽象 VD 类？第一步是弃用它们。我们可以修复任何受影响的树内驱动程序，但可能会有受影响的树外驱动程序。

结论

  • rosmaita 将向邮件列表发送说明，警告树外驱动程序维护者即将发生此情况。看看我们是否收到回复。

Cinder 节流和 cgroup v2

Cinder 已经使用 cgroup v1 进行（可选的、运营商配置的）节流很长时间了。cgroup v2 已经存在很长时间了，但没有一个很大的理由切换到 v2……直到 2020 年秋季，当容器系统开始支持 v2 时。所以现在 linux 发行版没有理由担心 v1 了，并且许多发行版正在使 v2 成为默认设置，并谈论删除 v1 支持。

鉴于以上情况，看起来我们可以直接切换到使用 cgroup v2，而不用担心也支持 v1。

libcgroup 库已经合并了代码（提交 9fe521f、8fb91a0、da13073）——但尚未发布——为我们当前正在使用的 cgroup 工具添加了 cgroup v2 支持，因此一旦发布，我们就可以使用当前的代码（对 v2 中用于 i/o 的不同控制组名称进行微小的更改）。

结论

  • 我们应该在 Xena 中将 cinder 迁移到使用 cgroup v2；此外，没有理由担心 v1 兼容性
  • rosmaita 检查新的 libcgroup 版本的状态并向 R-18 中期会议汇报（当前版本为 0.42.0，并且 2.0rc1 刚刚被标记，所以我们肯定能在 M-3 之前在 cinder 中完成这项工作）

与 Nova 的跨项目会议

关于本次会议的良好记录在 etherpad 上：https://etherpad.opendev.org/p/nova-cinder-xena-ptg

结论

  • cinder 团队对 Lee 的提案没有任何无法通过补丁解决的异议。
  • Nova 同意 cinder 更新 os-brick 的需求，尽管当前方法可能有点激进。

4 月 22 日星期四（驱动程序日）

录像

使用 Software Factory 进行 Cinder 第三方 CI

Pure Storage 的 Adam Krpan 发表了关于他如何使用 Software Factory 设置 Pure 的第三方 CI 系统的演示。这是指向录像的链接，从 7:06 开始：https://www.youtube.com/watch?v=hVLpPBldn7g&t=426，你可以自己看看。

这些是与此相关的有用链接

在讨论期间，Peter Penchev 提到他使用旧版本的 Software Factory 设置了 Storpool CI，但他还没有尝试升级。

结论

  • Adam 正在撰写一篇关于此的博文
  • software factory 第 3 方 CI 指南需要审查！https://softwarefactory-project.io/r/c/software-factory/sf-docs/+/17097
  • 听起来 Peter 和 Adam 使用 software factory 的体验总体上是积极的，因此 cinder 团队鼓励其他第三方 CI 维护者也了解一下——拥有一个 software factory 用户社区可以为 cinder 第 3 方 CI 带来很多好处

NVMe-oF 和 MDRAID 复制方法 - 连接器和代理的下一步

这是 Zohar 讨论的幻灯片：https://docs.google.com/presentation/d/1lPU8mQ7jJmr9Tybu5gXkbE7NC1ppkMnoBS4cgSFhzWc

这是指向录像的链接，从 46:42 开始，如果你想跟上进度：https://www.youtube.com/watch?v=hVLpPBldn7g&t=2802

Zohar 在 Wallaby 期间致力于升级 os-brick nvmeof 连接器，以便它可以在 hypervisor 上执行 mdraid（客户端复制）。在 Xena 中，他想添加一个 healing agent 以提高弹性。该 agent 将作为独立进程在 hypervisor 上运行，由操作员配置。

Gorka 建议代码可以位于 os-brick 中，并作为控制台脚本供操作员访问。这有点不标准，但它非常方便，因为该 agent 仅在安装 os-brick 的地方使用，因此代码就在那里。此外，就 Cinder 社区而言，具有控制台脚本的库似乎不会让我们感到困扰，因为我们已经在 cinderlib 中做过：https://github.com/openstack/cinderlib/blob/3f20993c2d8e5f9d4ce0fb250e5b186d3c3fbc73/setup.cfg#L36

结论

  • Kioxia 正在采取一种通用的方法来构建 agent，以便它可以作为其他使用 mdraid 的 nmveof 解决方案的基础，这些解决方案需要 healing agent
  • cinder 团队的共识是，将 agent 代码放在 os-brick 中并通过控制台脚本供操作员访问，比将 agent 代码放在自己的 OpenStack 项目中更好（减少了大量的项目管理开销）
  • 仍然存在一个未解决的问题：healing agent 将需要使用 cinder 中的 Kumoscale 驱动程序使用的 REST 客户端代码——我们能否在不复制它的情况下在 os-brick 中使用它？

如何处理将非加密卷重定型/迁移到相同大小的加密卷

弄清楚如何做到这一点正变得非常困难。Sofia 提出了她最新的想法。请参阅 etherpad 和录像以获取完整详细信息；我将尝试在此处提供快速摘要。


我们遇到的问题是加密卷的加密元数据存储在卷中。因此，加密卷的可用大小严格小于非加密卷的可用大小。此外，虽然非加密卷的可用大小可以通过最终用户清楚地知道（这是用户请求的 GiB 数），但非加密卷的可用大小却不清楚，因为加密标头的大小因加密方法而异（luks1 为 1-2 MB，luks2 最多为 16M）。因此，如果你填满了非加密卷，然后想将其重定型为加密卷，则该操作可能会失败，因为所有数据都无法放入可用空间中。当你在笔记本电脑上购买新驱动器时，这没什么大不了的：你知道加密它会损失一些空间。但这不是很“云”，因为云用户希望能够重定型卷（这可能需要迁移到不同的后端等），并且 2 GiB 的 A 类型卷应该可以重定型为 2GiB 的 B 类型卷。Gorka 指出这是 cinder 思考卷大小的一种范式转变（以及所有现有代码都是使用旧范式编写的）。

从镜像创建卷时也存在类似的大小问题：如果镜像的字节数几乎与请求的卷大小一样多，则镜像将无法放入加密卷中，即使用户期望如此，因为，例如，1073741000 字节 < 1GiB，该镜像应该可以放入 1GiB 卷中。

Sofia 的建议是，我们为每个卷提供“显示大小”和“真实大小”。显示大小是用户看到的内容，任何显示大小为 n 的卷都可以重定型为显示大小为 n 的卷，无论两者是否是加密类型。同样，1 GiB 的加密卷可以容纳 1073741824 字节的 glance 镜像。

（顺便说一句：在这种模型下，当加密卷上传到 Glance 作为镜像时，镜像大小将是卷的真实大小（以字节为单位）。因此，display_size==1GiB 的加密卷的镜像大小将严格大于 1GiB，这通常意味着它不能用于创建 1GiB 卷。但是它将具有 cinder_encryption_key_id 镜像属性，因此它可能会用于创建加密卷类型的卷（或者它将无法读取），所以也许这没有问题。我们不想强迫最终用户选择 2GiB 大小的卷来恢复 1GiB 卷的镜像。）

API 和配额/使用情况将使用显示大小，但 cinder 中的其他所有地方将使用真实大小。操作员可能需要真实大小用于会计目的，因此需要清楚地记录这一点，并且我们需要在卷创建通知中包含所有内容，以便会计可以决定如何收费：按显示大小、按真实大小、按用户大小加上加密溢价以弥补额外的空间，或……

我们必须弄清楚的一些问题

  • 我们需要一种通用的方法来处理不具有丰富功能集的驱动程序的重定型
  • 我们还存在 ceph 和 nfs 驱动程序使用 qemu-img 进行加密而不是 cryptsetup 的问题
  • 驱动程序差异
    • 一些驱动程序可能能够为我们提供请求的 GiB 大小加上一些 MiB 用于加密元数据
    • 有些可能只给我们 GiB 大小，所以我们必须请求 2 GiB 的卷来获得 1 GiB 的 display_size
    • 一些驱动程序只是以 8GiB 的倍数增加
  • 我们不想在相反的方向上创建一个相应的问题。也就是说，假设用户请求大小为 S 的加密卷。我们提供一个大小为 S + 一些松弛 M 的卷。假设加密标头使用 E，E 小于 M。如果用户能够填满 S + (M - E)，那么如果我们重定型为非加密卷，大小为 S，我们将无法将额外数据放入重定型卷中
  • 需要弄清楚对备份/恢复的影响
  • 需要弄清楚将卷上传到 Glance 作为镜像（以及从该镜像创建卷）的影响
  • 需要制定处理“遗留”卷的计划


我们需要更彻底地记录当前失败场景，然后我们需要新的 tempest 测试来测试这些场景。这将包括“填满”一个卷，然后确保重定型卷包含原始卷中的所有数据。Eric 有一个原型测试，它使用 md5sum 来验证数据：https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/785514

结论

  • 记录当前失败场景（包括备份/恢复和从镜像创建）非常重要；这将帮助我们评估提案
  • 我们必须区分 ceph/NFS 情况和“真实”块存储设备情况，因为它们可能需要不同的解决方案

小话题

驱动程序的 A/A 覆盖需要进行哪些门控测试？

我们目前没有任何 A/A 的门控测试。

结论
  • 一般建议是对 A/A 设置运行 tempest 和 cinder-tempest-plugin，因为这有时可以发现问题
  • 后续澄清是，所讨论的特定 A/A 设置是 DCN（“分布式计算节点”，又称“边缘”）。随着这种部署配置越来越受欢迎，可能值得设置一个门控作业。

在测试中使用 cinder oslo-versioned-objects (OVOs) 而不是字典

我只想指出 Gorka 在修复驱动程序错误时对单元测试进行的一个最近的小重构。

在 cinder 的最新版本中（其中“最新”比任何现有的稳定分支都要久远），驱动程序正在接收 Cinder OVO（Oslo Versioned Objects），但许多驱动程序的单元测试正在使用字典（因为字典早于 OVO，并且字典被认为更易于在单元测试中使用）。这不是一个好的做法，因为一些微妙的错误可能无法被检测到。此外，cinder 测试框架具有一些功能，可以轻松地创建和使用 cinder OVO，因此“字典更容易，它只是一个单元测试”的借口不再成立。

无论如何，重点是查看此示例，了解如何轻松地将代码转换为使用 OVO 而不是字典：https://review.opendev.org/c/openstack/cinder/+/766296/4/cinder/tests/unit/volume/drivers/netapp/fakes.py#80

结论
  • 开发人员和审查人员应在新测试中寻找此问题，并确保在适当的地方使用 cinder 对象
  • 驱动程序维护者应注意此问题，并在修改任何单元测试时进行重构

与 Glance 的跨项目会议

本次会议在 meetpad 中举行。没有录音。我的连接非常糟糕，此摘要主要来自 etherpad 上的注释：https://etherpad.opendev.org/p/cinder-glance-xena-ptg

Rajat（cinder 核心成员）正在帮助维护 cinder glance_store（它使用 cinder 作为 Glance 的存储后端）。cinder glance_store 非常原始，没有利用许多 cinder 功能。特别是，它不支持多挂载，这真的很糟糕，因为你可能会想到 Glance 的主要用例是让操作员拥有一小套公共镜像，这些镜像用于启动实例。因此，很可能存在多个并发请求来使用相同的镜像，并且如果没有多挂载，则一次只能满足其中一个请求，这会导致巨大的悲伤。因此 Rajat 提出了一项 glance 规范，该规范将为 cinder glance_store 添加多挂载支持。为此，他必须让 glance_store 适应 Cinder 的 Attachment API（在 ocata 中引入的微版本 3.27 中，已经存在一段时间了）。


这项更改不需要 Cinder 方面的任何工作，所以对我们来说没问题！

Erno 指出我们需要为操作员协作编写一些文档，以便有效地使用 cinder glance_store。例如，如果 cinder 后端将存储 glance 镜像的地方可以进行多挂载，则操作员应为该后端创建一个支持多挂载的卷类型，并且该卷类型应由 cinder glance_store 使用。我们应该收集一些最佳实践（例如，在 cinder 端使用 image-volume-cache，即使 Glance 不使用 cinder glance_store，这可能也是一个好主意）。

结论

  • Rajat 将继续进行 cinder glance_store 多挂载规范和补丁
  • 最好让某人开始编写 cinder glance_store 的最佳实践文档

4 月 23 日星期五

录像

市场趋势和新的 cinder 功能

我们快速讨论了 cinder 中的功能开发是如何驱动的。目前，我们的项目重点是稳定性和减少技术债务（例如，删除 Block Storage API v2，摆脱 sqlalchemy-migrate，实施默认安全的 RBAC），并且我们依赖于人们在 PTG 中提出功能主题并提出规范。换句话说，项目团队主要是在寻找需要修复的东西，而不是需要实现的新功能。

NetApp 的 Jake Thorne 提到，我们可能应该更加积极地确保 OpenStack 不会过时，与当今人们对云的期望不符。他“自愿”组织一个演示或讨论或其他内容，以让 cinder 团队了解当前的市场趋势。每个月的最后一次 cinder 会议（我们通过视频会议举行）是一个好时机，或者在 R-18 中期会议上，或者我们可以有一个新的每月会议专门用于此主题。项目团队似乎有足够的兴趣，所以这取决于产品经理和其他密切关注市场趋势的人员来展示或领导讨论。

结论

  • Jake 将准备一些内容；Kioxia 的 Chuck Piercey 自愿提供帮助
  • Cinder 团队认为这是一个好主意；一旦 Jake 和 Chuck 确定了第一次讨论的格式和日期，我们就可以将此信息传达给我们的经理，我认为他们也会感兴趣，并希望帮助开发更多主题

已挂载卷的快照

Eric 注意到我们允许用户对已挂载的卷进行快照，但他们必须在请求中使用--force 标志。这似乎有点毫无意义，特别是由于他怀疑实际用例是在挂载时进行快照，因此让人们选择加入预期行为有点愚蠢。此外，nova 和 cinder-csi 始终使用设置了该标志进行调用。

Eric 的观点是，人们期望的快照是崩溃一致性。Gorka 建议可能并非所有最终用户都理解这一点，并且 --force 标志提醒他们他们只能获得崩溃一致性。Simon 提到，几乎在所有地方，当你请求快照时，你都会得到一个快照，并且由你来了解含义。Eric 认为我们不通过不执行其他人所做的事情来获得太多好处。

有人提到从 nova 端创建快照时，实例会在创建快照之前被静默。因此，我们可以增强文档，解释 cinder 提供崩溃一致性，如果需要静默，则从 Compute API 创建快照。

Walt 提到备份方面也有类似的情况，人们想要备份附加卷，但我们需要 --force 标志才能执行此操作。上传卷到镜像的操作也存在这种情况。

结论

  • Eric 将继续处理这个规范：https://review.opendev.org/c/openstack/cinder-specs/+/781914
  • Eric 还会研究备份和上传卷到镜像的情况，并决定是否可以在同一个规范中处理它们
  • 关于快照/备份/镜像为崩溃一致性的文档应该添加到 api-ref 中，以便最终用户可以看到它

多个卷进入同一个后端/池，作为调度器实例（HA）仅使用其内部状态在池之间平衡卷

该问题在我们的文档中有所描述：https://docs.openstack.org/cinder/victoria/contributor/high_availability.html#cinder-scheduler

Fernando 想知道文档中描述的“正在进行的修复此问题的努力”的进展情况，因为他有一个客户遇到了这个问题。

目前，“正在进行的努力”是变通方法。您可以做的一件事是在调度器中使用随机权重来缓解此问题。

Ivan 指出，重要的是要知道操作员的目标是真正的 A/A 还是他们想要的是 H/A。Walt 描述了一种“半 A/A”设置，它具有多个 API，但只有一个调度器（因此调度器永远不会不同步）。这种设置解决了 API 节点因请求饱和的问题（用户、脚本检查资源状态等）。调度器具有正常的 cpu、内存，并且能够跟上配置请求。 （基本上，GET /volumes 是免费的，所以用户会发出很多调用，但 POST /volumes 需要付费，所以用户只有在真正需要时才会发出配置请求。）

有一个相关的规范：https://review.opendev.org/c/openstack/cinder-specs/+/556529 (“迁移到使用数据库获取调度器信息”)。数据库可能不是理想的选择，所以可能是 memcached 或 redis。关键是我们需要共同的存储，因为我们不能依赖于从后端获取统计信息的进程足够快，以便我们可以直接询问后端当前的状态。

但是，如果我们真正追求的是 H/A，我们可以使用锁，这将有效地序列化多个调度器的请求，但这对于 H/A 来说是合适的。

结论

  • 这是一次很好的讨论，如果您对这个问题感兴趣，可以找到录像观看。

使备份过程异步

Walt 已经为此问题提出了 WIP 补丁：https://review.opendev.org/c/openstack/cinder/+/784477

基本上，随着被认为是“正常”卷大小的增加，执行备份所需的时间也增加了。因此，2TB 的卷可能需要大约 10 小时，所以我们遇到了 RPC 超时和备份失败。大致来说，当用户请求备份时，卷会被克隆，然后克隆会被上传到备份后端，这两个步骤都需要很长时间。

Walt 的解决方案是将 RPC 调用更改为 casts。代码更改很简单，但重构单元测试很困难。Walt 计划包含兼容性代码以处理滚动升级。

结论

  • Walt 将继续处理这个问题。

几个小主题

按错误状态查询的卷列表应包含 error_managing 状态

https://review.opendev.org/c/openstack/cinder/+/740152

需要加快对这个补丁的审查速度并修复这个特定的错误，然后跟进一个更彻底的修复，删除这些奇怪的状态。

Gorka 提出了一个补丁，以引入一个新的数据库列用于配额，这可能会消除其中一些。

我们应该使用用户消息将这些信息传递给最终用户，而不是试图将其偷偷塞入状态字段。

结论

支持将任何快照还原到卷

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

规范中仍然没有解决的一个问题是最终用户将如何看到快照链（它从线性变为树形）。

大多数现代存储可以以有效的方式做到这一点，所以即使最低公共分母的性能很差，也有充分的理由允许这样做。可能要求驱动程序来做，如果它不能，则使用 LCD 方法。

结论
  • 仔细审查规范，以便可以开始编码

服务重启后更新卷可用区，如果卷后端可用区已更改

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

结论
  • 这似乎更适合在 cinder-manage 工具中实现，而不是我们尝试自动执行的事情。

OpenStack 客户端仍然不支持 cinder 微版本

目前，cinder 在 osc 中的微版本支持必须为每个 mv 添加。例如：https://review.opendev.org/c/openstack/python-openstackclient/+/761633

OpenStack SDK 应该支持微版本，但它也被认为是一个“有偏见”的 OpenStack API 接口。如果是这样，它就不能取代 cinderclient，因为我们需要为整个块存储 API 提供 python 语言绑定。

人们想要使用 osc。我们可以在 cinder 端做的一件事是为任何新的微版本添加对 osc 的支持。这无助于补救问题（目前 cinder 在 3.64，osc 支持一个 mv (3.42)），但应该有所帮助。一个问题是块存储 API 将对 mv 3.64 的请求解释为对 3.1 到 3.64 的请求。因此，对最新 mv 的请求可能包含 osc 尚未准备好的 API 响应中的某些元素。但我们可以在发生时处理它。

结论

  • 引入块存储 API 的新微版本需要 cinderclient 补丁和 osc 补丁才能合并。（但是，我们不会要求在合并 cinder 补丁之前合并 osc 补丁。）

一致且安全的 RBAC

这是所有使用策略的 OpenStack 项目之间的大型合作努力，因为，基本上，直到每个人都支持自 Queens 以来的 keystone 中的更改（！），他们才能被任何人使用。它们对操作员来说是一个巨大的胜利，因为它们促进了操作员多年来一直要求的默认策略配置，但使用预 Queens-keystone 策略范例（这是 Cinder 处理策略的方式）实现起来非常复杂。2020 年用户调查表明 Cinder 被用于 87% 的 OpenStack 安装，因此这会影响很多操作员，并在本开发周期内完成这项工作是优先事项。

Lance 在 OpenStack 上提供的当前状态的通用摘要，以及指向更多信息的链接：http://lists.openstack.org/pipermail/openstack-discuss/2021-April/022117.html

大致来说，Keystone 在令牌上提供了两个维度：范围和角色。目前 Cinder 仅识别角色，但可以轻松转换为识别项目范围 + 角色。获得 Cinder 识别系统范围需要更多的工作，但看起来我们有前进的道路。所以需要完成以下工作

  1. （最终）默认配置的自然语言描述。这将对操作员有所帮助，但也发现了一些当前 cinder 策略中的不足。它还为我们提供了一个验证默认策略测试的东西。
  2. 策略更新补丁（添加项目范围）：https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac
  3. 测试补丁。基础补丁是 https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915（现在可以安全地合并）。初始测试补丁：https://review.opendev.org/q/project:openstack/cinder-tempest-plugin+topic:secure-rbac
  4. 客户端更改以支持系统范围：https://review.opendev.org/c/openstack/python-cinderclient/+/776469
  5. 放宽 cinder REST API 以处理系统范围：https://review.opendev.org/c/openstack/cinder/+/776468

我们仍在研究如何处理块存储 API v3 URL，这些 URL 主要需要在路径中包含 project_id。使用管理员使用的纯系统范围令牌时，没有关联的项目。当前的想法是在系统范围工作时使用 00000000-0000-0000-0000-000000000000 作为填充，并增强 cinderclient 以适当使用它（并为直接与 API 交互的管理员/脚本记录此信息使用 curl 或 requests 库）。

虽然我们不会将利用域范围的 personas 作为这项工作的一部分来实现，但我们需要确保我们不会做出任何需要以后进行重大重构的设计决策。

结论

  • 我们可以立即开始进行自然语言描述，以及项目范围的更改（链接到上面的补丁）；目标是在 milestone-1 之前完成这部分工作
  • 同时进行支持系统范围所需的更改，并在 milestone-2 之前完成

Xena 周期优先级

整个周期

  • 解决上游 CI 中的稳定性问题：在您的补丁中使用 gerrit 主题 cinder-xena-ci-stability
  • 改进 cinder-tempest-plugin 中的测试覆盖率（包括在 PTG 上讨论的新配额测试）：使用 gerrit 主题 cinder-xena-ci-coverage
  • 解决 cinder 项目交付中任何地方对已弃用内容的用法（即在 cinder、os-brick、cinderlib、python-cinderclient、python-brick-cinderclient-ext、rbd-iscsi-client 中）：在您的补丁中使用主题 cinder-xena-cleanup
  • 驱动程序：第三方 CI 稳定性
  • 社区建设

在 Xena milestone-1 之前

  • 从客户端中删除块存储 API v2 支持
  • 从 cinder 中删除块存储 API v2
  • 安全的 RBAC

在 Xena milestone-2 之前

  • 完成安全的 RBAC
  • 将 sqlalchemy-migrate 替换为 alembic（将在 R-18 中期会议上讨论）

在 Xena milestone-3 之前

  • 批准的规范和驱动程序功能蓝图的补丁
从 "https://wiki.openstack.org/w/index.php?title=CinderXenaPTGSummary&oldid=178409" 检索