跳转到： 导航, 搜索

CinderWallabyPTGSummary

目录

简介

此页面包含 2020 年 10 月 26 日至 30 日举行的 Wallaby PTG 中 Cinder 项目会议讨论主题的摘要。Cinder 项目团队从 10 月 27 日星期二到 10 月 30 日星期五举行会议，每天 3 小时（UTC 1300-1600），并安排额外一小时用于“走廊时间”，但周三和周四的走廊时间用于与 Glance 团队的跨项目会议。

2020 年 10 月 Wallaby（虚拟）PTG 的 Cinder 团队。


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


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

星期二 10月27日

录像

峰会后续

代码/文档/基础设施中的分裂性语言

基本思想（来自 [0]）： “OpenInfra 基金会 (OIF) 董事会支持从其生产的软件和文档中删除成员认为具有压迫性、种族主义和性别歧视性的措辞。虽然我们知道会面临技术和非技术方面的挑战，但我们认为这是一项重要行动。”

推动这项工作的团队上周举行了论坛会议，并在 PTG 昨天举行了会议


Rosmaita 报告了对 cinder 代码库进行快速 grep，以查找 master/slave 和 blacklist/whitelist 的明显冒犯性用法

  • 在 cinder 的主代码中，“slave”显示为一些 oslo.db 库调用的参数，因此在修复之前我们无法更改它
  • 在一些驱动程序中使用 master/slave
  • 在一些驱动程序中出现 blacklist/whitelist


Amy Marrich (spotz)，她是推动这项工作的团队成员，参加了会议并向团队强调了一些要点

  • 该团队正在向 TC 提出“立场”。获得批准后，它将为各个项目团队提供一些指导
  • 我们不是唯一这样做的一个开源社区；etherpad 上有一个其他开源项目及其所做的/正在做的更改的列表
  • 不需要追溯并更改我们历史中的所有内容，但项目应遵循新代码/文档中的指导
  • 项目可以使文档更具包容性，而无需在代码中进行更改
  • 想法是让项目做出适当的更改；没有计划通过生成补丁来更改所有项目的“master”以引入混乱
  • 等待查看上游 git 如何处理“master”作为默认主分支名称。Github 已将其更改为“main”用于在 github 上创建的新项目

当前的 Cinder PTL 个人支持这项工作，因为它以深思熟虑的方式进行，并且所有更改都将通过正常的代码审查流程 [1]。此外，一些雇主（例如 Red Hat [2]）正在鼓励他们在参与的开源项目中进行这项工作。

[0] https://etherpad.opendev.org/p/vSummit2020__DivisiveLanguage
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018181.html
[2] https://#/en/blog/making-open-source-more-inclusive-eradicating-problematic-language

结论
  • 我的感觉是 cinder PTG 会议中 cinder 团队普遍支持这项工作（或者至少不反对它）。在实践中，这意味着不允许将非包容性术语引入新的文档/代码
  • 对现有代码的更改将在 Gerrit 中像往常一样进行斗争
  • 操作 - rosmaita - 在 TC 提案获得批准后，更新 cinder 代码审查指南以提及这一点

openstackclient 的情况

这在上周的论坛上讨论过：https://etherpad.opendev.org/p/vSummit2020_FeatureGap

似乎仍然处于相同的情况，即

  • 需要更好地支持微版本
  • 仍然太大（需要许多依赖项）


至少一些运营商真的希望只有一个客户端可以使用，但首先 OSC CLI 和各个项目 CLI 之间需要功能奇偶校验。

结论
  • 从我的角度来看，关键是 OSC-everywhere 不会成为本周期的社区目标
  • 对这项工作感兴趣的 cinder 团队成员应联系 Stephen Finucane（nova core，其他一些项目的核心）以帮助使其发生
  • 操作 - rosmaita - 这在 PTG 稍后出现了，但我们需要确保正在使用 openstackclient 的团队知道 python-brick-cinderclient-ext 支持在 OSC 中是一个重要问题

Wallaby 社区目标

目前，只有一个目标被接受（尽管看起来还会有另一个，请参见下一节），即“从 oslo.rootwrap 迁移到 oslo.privsep”：https://review.opendev.org/#/c/755590/

Cinder 在使用 rootwrap 的项目列表中，但我看了一下，我认为它只是关于使用 rootwrap 来升级以运行 privsep（而且似乎没有其他方法可以做到）。作为目标的一部分，将引入一个 hacking 检查以确保人们没有使用 rootwrap。

该目标的精神（虽然不是必需的）是确保项目使用良好的 privsep 规则，而不是开放的规则。我们可能需要花一些时间来使用 python 命令来完成我们需要的事情，而不是仅仅调用 CLI 来完成它们。因此，我们可能希望投入一些时间来使我们当前的 privsep 调用使用 python 代码。

结论
  • 看起来 cinder 可以轻松满足目标的“字面意义”
  • 团队中对安全感兴趣的任何人……最好研究一下满足目标的“精神”，因为这对项目来说是好的

“一致且安全的策略”更新

有一个“策略弹出组”正在进行这项工作。他们在论坛上举行了会议，并在 PTG 上举行了会议。


普遍认为这项工作需要完成才能最终关闭 Bug #968696（“管理员无处不在就是管理员无处不在”），这是一个如此古老的错误，它只有 6 位数字（Adam Young 写了一首歌的那个）。看起来它将分两个阶段进行


在 Wallaby 期间，在 Cinder 中，我们需要进行测试覆盖，以定义基本的策略行为。Rajat 已经开始这项工作，并将系统范围纳入了新的项目级别默认卷类型 API。Lance Bragstad 提出了一些补丁来帮助我们：https://review.opendev.org/#/q/topic:secure-rbac+project:openstack/cinder

结论
  • 我们看起来对 W 来说还不错
  • 操作 - rosmaita - 在提供语言后，发布 policy.json 弃用说明
  • 在 W 期间完成基础“X”工作对于在 X 周期内实现 X 目标至关重要

移除嵌套配额驱动程序

Rajat (whoami-rajat) 指出，嵌套配额驱动程序在 Train 版本中已被弃用，并计划在 Ussuri 版本中移除，而是致力于支持范围和统一限制。Rajat 已经提交了一个补丁来移除它：https://review.opendev.org/#/c/758913/

没有人反对提出的移除方案；弃用期已经过去很久了。

Rajat 计划后续跟进一些代码，以修复我们查询/设置配额的方式。目前这段代码没有验证机制，因此操作员在设置配额时可以使用项目名称，API 会报告成功。但由于应该使用 UUID，因此此类配额永远不会应用，因为 cinder 没有记录将配额分配给该项目的记录。这既让操作员感到困惑，一旦他们弄清楚发生了什么，又会让他们感到烦恼。Gorka 指出，他已经看到很多下游错误与此问题有关。

结论

  • Rajat 在 microversion 3.62 中添加了项目 ID 验证，并且没有人提出异议，因此看来我们已经同意 cinder API 调用可以调用另一个服务（当然，在合理范围内）。
  • 默认情况下，这是一个面向操作员的调用，所以 API 不会被这些请求轰炸。

清理改进

Gorka (geguileo) 指出，我们在启动时（或当我们请求作业清理时）的资源清理非常糟糕。（我们说的是服务停止并重新启动时该怎么做。这对于主动/主动配置很重要。）

例如，在启动时，我们会查看处于“-ing”状态的卷

  • 如果状态为 'creating'，我们将卷设置为 error
  • 如果状态为 'downloading'，我们将卷设置为 error
  • 如果状态为 'uploading'，我们将状态更改为 'available' 或 'in-use'，具体取决于卷是否有任何挂载
  • 如果状态为 'deleting'，我们将重试该操作（这正是我们应该做的，因此此状态正在被正确处理）


类似地，对于备份

  • creating => Detach volume + Restore volume to previous status + Set backup to error
  • restoring =>Detach volume + Set volume to error_restoring + Set backup to available
  • deleting => 这一个没问题，我们会重试该操作


Gorka 的想法是，我们拥有这些“-ing”状态的元数据，因此我们可以尝试像处理 'deleting' 状态一样处理它们，即重试该操作。有人指出，对于 'creating'，卷实际上可能已经在后端创建，但 cinder 在能够发现它之前就崩溃了。但我们可以先发出 'delete'，然后再重试创建。此外，调度器中也有一些重试机制，所以我们已经在做一些了。最好对此更加彻底一些。

结论

  • 没有人认为这需要一个规范，所以我们将跟踪一个蓝图。
  • 没有人反对实施上述内容，所以 Gorka 可以自由地继续进行。

配额：“移除配额使用缓存”

我们将在数据库中存储配额和使用信息，以便快速响应各种查询，但数据库“缓存”会与实际使用情况不同步，因此人们会得到异常结果，操作员不得不手动清除。Sam Morrison 提出一个规范 [0] 来解决这个问题，但一些请求的修改没有完成，并且它没有被批准用于 Victoria。在 Victoria PTG 上对 Sam 提案的主要反对意见是动态查询数据库的性能影响，每次 cinder 需要原本应该在缓存中的信息时，Sam 确实在规范中添加了一些性能信息。

在 Wallaby PTG 上讨论此事的目的是确定 Sam 提供的性能信息是否足够，或者我们是否需要更好的性能信息，如果是这样，我们想要什么，以便我们可以采取行动。

Gorka 指出，如果存在一些性能影响，我们可以通过重构与我们使用 oslo 版本化对象相关联的数据库代码来平衡它，当我们查询数据库多次以获取我们已经从早期查询中获得的信息时，会进行很多调用。

Eric 认为，虽然规范给人留下深刻印象，认为这很简单，但实际上它将对代码产生显着影响。然后问题来了规范是否需要更多细节，但 Eric 指出原型代码比非常详细的规范更有帮助。Rosmaita 询问是否有人目前正在处理此问题……显然没有人。但我们仍然希望有人能接手。

[0] https://review.opendev.org/#/c/730701/

结论

  • 行动 - rosmaita - 修改当前规范（或向 Sam 发送电子邮件要求他这样做；当前反对意见是格式问题），目标是 Wallaby

使卷驱动程序接口更加健壮

引发此问题的是一个反向移植错误，其中一个驱动程序函数被移除；这在最新分支中是可以的，因为该函数已被重构到基类，但在早期分支中，重构尚未完成，并且没有被任何单元测试捕获。

拥有更详细的驱动程序 API 会有所帮助。Sean 指出，实际上 [0] 中定义的接口类就是这个目标。这些用于生成 API 文档 [1]，并且也用于 'tox -e compliance' 测试环境，该环境验证驱动程序是否满足接口。

我们目前的做法是在需要时更改驱动程序 API，并测试树内驱动程序并修复任何中断。这无助于树外驱动程序，但这似乎不是在场者中的主要问题。

当前驱动程序 API 的一些内容对于参数和返回值中的对象与字典而言并不明确。Eric 在添加类型检查方面的工作最终应该会改善这种情况。

一个使情况复杂化的因素是，我们仍然拥有所有的抽象基类代码。这是一个问题，因为新的驱动程序编写者可以在他们实现驱动程序时使用 ABC 类或只是基驱动程序类。Eric 确信类型检查代码将为我们带来原本应该来自 ABC 代码的许多好处。

[0] https://opendev.org/openstack/cinder/src/branch/master/cinder/interface
[1] https://docs.openstack.org/cinder/latest/contributor/drivers.html#base-driver-interface

结论

  • Sean 组装的接口类将被视为驱动程序接口的真实来源
  • 行动 - rosmaita - 审查接口类及其文档字符串，并在适当的地方将类型信息添加到文档字符串中；更新 cinder/volume/driver.py 中的文档，以确保人们在正确的位置查找类型信息
  • 最终，应该删除 ABC 代码

词汇分钟

有一些含糊的术语，我们需要小心使用，以避免规范、代码和策略中产生混淆。

  • 'user'
    • 可能是最终用户或操作员或两者兼而有之；请明确您在说什么
  • 'admin'
    • 这因 Keystone 中添加的新范围而变得复杂。现在有不同类型的“管理员”。
      • '系统管理员'……具有系统范围的管理员。（这是我们以前所说的“cinder 管理员”的新名称。）
      • '项目管理员'……对特定项目具有某种管理权限的用户（我们以前称之为租户），但他们不超出该范围。例如，在项目级别默认卷类型 API（mv 3.62）中，项目管理员可以允许设置项目的默认卷类型（租户），但该项目中的“普通”用户不允许；项目管理员无法为不同的项目设置默认卷类型（而系统管理员可以）。
      • '域管理员'……基本上，可以在分组到域中的所有项目上执行项目管理员操作（比简单的项目管理员多，但比系统管理员少）
    • 目前，Keystone 中的管道已经到位，用于这些不同类型的管理员，但 Cinder 侧需要进行策略更改才能使其生效（请参见上面的“一致且安全的策略”更新部分）。
    • Keystone 文档中有一个入门指南，解释了每个角色/范围的组合以及它们应该如何表现：https://docs.openstack.org/keystone/latest/admin/service-api-protection.html
  • 'migrate'
    • 这是一个 cinder 特定的操作名称；也许我们应该将其称为“移动卷”，这可以通过 retype 或 migrate 操作来完成
  • 'backend'
    • 我们到处都在使用它，甚至在我们的标志中……但我们的意思是
      • 存储阵列
      • cinder 卷服务
      • 主机/集群 DB 字段和消息队列中的后端部分？
      • volume_backend_name
    • 甚至拼写也受到质疑：一些技术作者建议在用作名词时使用“back end”（两个词），在用作形容词时使用“backend”（一个词）

结论

  • 在编写规范、文档和代码时，我们需要明确使用该词时所指的意思
  • 审查者也应该意识到这一点，并要求作者澄清
  • 行动 - geguileo - 为贡献者文档起草一份初始文档，解释这些区别


然后团队 adjourn 到 meetpad 进行欢乐时光，并欢欣鼓舞。

10 月 28 日星期三

录像

TC 会议更新

Jay (jungleboyj) 向我们通报了 TC 会议的情况。Wallaby 看起来将有两个目标，privsep 移除和将默认策略文件从 JSON 迁移到 YAML。

对于 privsep 目标，https://review.opendev.org/#/c/755590/

  • 可以使用 rootwrap 来提升 privsep 进程，但希望将来会有更好的方法来做到这一点。


策略文件迁移目标由 https://review.opendev.org/#/c/759881/ 提出；这与我们昨天讨论的内容大致相同（见上文）。

关于 OpenStack Client 的情况，TC 正在考虑一项决议，以阐明其对该问题的“立场”：https://review.opendev.org/#/c/759904/。就 cinder 本身而言

  • openstackclient 确实支持添加插件
  • 不幸的是，当前 osc 中的卷支持不使用插件，并且实际上命令结构的设计方式使得编写一个简单的插件来适配 python-cinderclient 代码会很困难。它需要某种翻译层（这将扩展复杂性和因此错误表面）
  • 不清楚是否有办法在 osc 中处理 os-brick-ext 功能
  • osc 中有 microversion 支持，并且它似乎适用于 nova

结论

  • 行动 - rosmaita - 更新 cinderclient-openstackclient 功能差距电子表格，以评估当前差距（需要查看 mv 3.55-3.62 支持）：https://ethercalc.openstack.org/cinderclient-osc-gap
  • 行动 - rosmaita - 与 osc 团队跟进有关 microversion 支持的问题，以及它是否适用于 cinder 请求
  • 行动 - rosmaita - 确保 osc 团队意识到 brick-cinderclient-ext，并且 osc 必须支持类似的东西

Kioxia：添加新驱动程序

Kioxia KumoScale 团队希望在 Wallaby 中贡献一个 cinder 驱动程序。他们进行了一次演示 [0]，概述了 KumoScale 的工作原理以及他们需要实现的内容，并获得了 cinder 团队的反馈。

该驱动程序将是一个相当标准的 cinder 驱动程序。它需要一个新的 os-brick 连接器，Kioxia 建议通过基于 nvme-of 协议的改进来增强当前的 nvme-of 连接器，这将使这些功能可供社区使用，然后将其用作 kioxia 连接器的基类。

他们希望开源所有代码，并且正在处理许可问题。他们指出，操作员不希望在他们的计算节点上运行非开源代码。Kioxia 将部署一个修复代理，因此他们非常希望使其开源。

有关更多详细信息，请参阅幻灯片 [0] 和 PTG etherpad。

在讨论过程中，Gorka 注意到当前 os-brick 代码中可能存在一个错误，即看起来我们在断开连接之前没有刷新 nvme-of 连接器。有关详细信息，请参阅 etherpad。

[0] https://docs.google.com/presentation/d/18zBxXfDTOieuD-lQmz4Cx2xBiTErjfXy9eRsMuYZxJI/

结论

  • Kioxia 团队将为他们的驱动程序和 os-brick 连接器工作提交蓝图（并完成工作！)
  • 行动 - geguileo - 提交一个关于非刷新问题的错误

图像加密工作更新

Josephine (Luzi) 向我们通报了正在进行的图像加密工作。Barbican 决定他们需要 microversion 才能引入“Secret Consumer API”（它是 barbican 密钥的消费者 API，而不是一种拥有未知消费者的方式）；此 API 对于加密工作很重要，因为它将允许服务注册它们拥有的依赖于密钥的资源，这样用户就可以在想要删除当前正在使用的密钥时收到警告（因为删除密钥显然会使资源无法使用）。

加密和解密代码将进入 os-brick（我们可能在两个周期前批准了规范）。它可以独立审查，并且与正在进行的其他工作无关。

Glance 仍然存在一些挑战，但一旦这些问题以及 castellan 对 Barbican secret consumer API 的支持发生，就可以添加 cinder 代码来消费和上传这些图像。因此，看起来所有这些都可能在 Wallaby 中实现。

结论

  • gpg 加密支持的 os-brick 补丁已准备好进行审查：https://review.opendev.org/#/c/709432/
  • 我们还对 Barbican Secret Consumer API 感兴趣，将其作为一种使我们当前 LUKS 的加密密钥处理更加健壮的方法

加密卷大小调整（续）

Sofia (enriquetaso) 报告了她正在进行的工作，以修复一个最初看起来很简单，但实际上在多个不同层面上都很复杂的错误，相关讨论在此 etherpad 上：https://etherpad.opendev.org/p/sizing-encrypted-volumes

简而言之，问题在于 LUKS 加密的容器必须包含一个头部。因此，当前，当用户请求 1GB 的加密卷类型时，他们实际得到的大小会略小（即，1GB 减去头部所需空间（随 LUKS 格式而异））。我们尚未收到任何关于此的投诉（！），但当用户尝试将非加密卷类型重新调整为加密卷类型时，我们会收到投诉；当 cinder 尝试将 1GB 的卷放入没有完整 1GB 剩余空间的卷中时，卷创建会失败。

我们讨论了引入一个 'migrate_size' 的想法，以便从非加密卷类型到加密卷类型的重新调整的用户可以指定更大的大小。Gorka 指出这只是将问题转嫁给用户。此外，cinder 以 GB 为单位指定大小，而我们真正需要的最多只有几 MB。此外，我们会有这样一种奇怪的情况：用户有一个 1GB 的非加密卷，重新调整为 2GB 的加密卷，重新调整为 2GB 的非加密卷，然后决定再次重新调整为加密卷，现在卷是 3GB，尽管用户不需要那么多。Gorka 认为这是一个驱动程序问题，关于如何处理必要的额外空间，以便 x GB 的卷实际包含 x GB，无论它是作为加密卷开始，还是从非加密卷重新调整为加密卷。因此，我们需要找到一种方法让每个驱动程序告诉 cinder 它可以分配空间的增量大小。虽然这意味着 2GB 的加密卷在后端将占用超过 2GB 的空间，并且报告的卷大小仅为 2GB，但操作员可以对加密卷类型略微提高价格，以考虑实际的空间消耗（或者可能某些后端开销太小，不值得担心）。

结论

与 Glance 团队的跨项目会议

我们首先讨论了 cinder 在使用 NFS 后端时 glance_store 的情况，但很快就意识到这需要更长时间的讨论（将于周四举行）。

我们还讨论了 'cursive' 库的状态，nova、glance 和 cinder 都使用它来进行图像签名验证。它目前在 'x' 命名空间中：https://opendev.org/x/cursive 但实际上应该成为 openstack 的一部分。

结论

  • cursive 库应该位于 oslo 中，由使用团队共同维护
  • 行动 - rosmaita - 将此事告知 oslo 团队

10 月 29 日星期四（Gorka 的日子）

我们宣布今天是“Gorka 的日子”，因为他贡献了许多需要讨论的话题。

录像

重置状态的健壮性

Tushar Gite (TusharTgite) 提出了这个话题，作为一位修复了一些错误，但希望提交功能并寻求指导的开发人员。他正在考虑采用这个规范：https://review.opendev.org/#/c/682456（重置状态的健壮性）。

该规范的当前状态是，它最初是为 victoria 提出的，获得了积极的评论，但没有及时修改以符合 Victoria 规范冻结。因此，第一步将是接管规范并将其重新提出给 Wallaby，并进行请求的修改。有人指出 Cinder 开发人员指南会有帮助，特别是这部分：https://docs.opendev.org/opendev/infra-manual/latest/developers.html#rebasing-a-commit

该规范的基本思想是，Cinder 具有卷的“重置状态”功能，但存在几种条件（在规范中标识），在这些条件下，Cinder 应该知道重置到请求的状态会导致无效条件。（一个例子是获取具有活动附件的卷并将状态重置为“可用”。）在这种情况下，Cinder 应该拒绝带有信息性错误消息的请求。

规范中指出，有时知识渊博的操作员可能需要重置状态，然后手动使当前状态有效。规范中有一个关于是否应该在 API 中包含一个 '--force' 标志的问题，或者是否应该将其移出 API 到 cinder-manage。团队讨论了这个问题，并决定 cinder-manage 是允许强制更改的地方。

Gorka 指出我们需要小心处理这个问题，不要简单地在 Cinder DB 中进行更改，这些更改不反映后端资源的状态（例如，我们可以在数据库中删除卷的所有附件，这将释放卷以供删除，但如果后端不知道这一点并认为附件仍然处于活动状态，某些后端将不允许删除该卷）。

另一个出现的问题是，我们需要让操作员了解“新的”Attachments API（在 Ocata 中引入的微版本 3.27！）。如果他们使用 Attachments API 删除所有附件，则卷应该再次变为可用，而无需重置状态。

结论

  • 强制状态重置是允许的，但不是通过 API ... 你必须使用 cinder-manage
  • Jay (jungleboyj) 乐于回答有关更新和移动规范的问题
  • Eric (eharney) 作为原始作者，将可以回答有关内容的问题
  • 行动 - TusharTgite - 接管 https://review.opendev.org/#/c/682456 并按照上述讨论重新提出
  • 行动 - rosmaita - 有一个未决的补丁与“卷列表优化”规范相关（结果是一组错误，而不是新功能）。这里的重点是它处理一些仅供内部使用的状态值，这些状态值不应该暴露给用户；需要对该补丁进行审查，并确保我们不会通过 API 泄露这些仅供内部使用的状态。

Ceph：支持的最低版本

对于 cinder RBD 驱动程序，我们没有指定我们支持 Ceph 的哪个版本范围。这正在成为一个问题，因为较新版本的 Ceph 中有我们想要利用的功能（例如，clone v2 API），如果我们致力于支持较旧版本的 Ceph 而没有这些功能，我们要么必须添加大量的兼容性代码，要么可能创建两个 RBD 驱动程序的子类，并根据最小 Ceph 集群版本选择使用哪个子类。但最好避免额外的复杂性，特别是如果没有人使用较旧的版本。

Ceph 社区每年发布一个版本，目标是 3 月 1 日。“稳定发布系列的生命周期计算为大约 24 个月（即，两个 12 个月发布周期）”[0]。因此，现在他们官方支持的只有 Nautilus 和 Octopus。

我们发送了一份操作员调查；结果在此处：https://docs.google.com/spreadsheets/d/1bjh4o4piczet2u6EjiPRvgmS10HdXluFruoGmLSEaMw

看起来与 OpenStack 一起安装 Ceph 集群的客户会在更新 OpenStack 时进行更新。此外，拥有外部集群的人倾向于遵循其操作系统发行版中可用的内容，这不一定与 Ceph 项目当前支持的内容一致。

看起来运行非常旧的 Ceph 的人计划至少升级到 Mimic。这对我们来说很好，因为 Mimic 包含我们想要在 RBD 驱动程序中使用的 clone v2 API，并且它将允许我们说我们支持 Ceph 项目支持的版本 + 1 年，这似乎是合理的。

问题出现了 Ceph 客户端版本？大家一致认为，在 OpenStack 安装中，客户端和服务器版本应该保持一致。但是，我们应该明确说明这一点。

[0] https://docs.ceph.net.cn/en/latest/releases/general/

结论

  • 提案：cinder 仅支持当前 Ceph 项目活动稳定版本加一个版本
  • 行动 - rosmaita - 起草一封电子邮件给操作员，概述此计划，并查看我们收到的回复
  • 行动 - rosmaita - 确定这将在文档中放在哪里，并确保明确说明客户端-服务器版本对齐。

Ceph：我们应该更改 rbd_exclusive_cinder_pool 默认值吗？

rbd_exclusive_cinder_pool 选项是在 Queens 中由 Change-Id: I32c7746fa9149bce6cdec96ee9aa87b303de4271 添加的，默认值为 False。

此项为 False 的一个含义是，随着卷数量的增加，服务启动所需的时间越来越长，因为必须检查所有卷才能查看它们是 Cinder 卷还是不是。大多数部署使用专用的 ceph 存储池用于 cinder，因此将此选项设置为 False 只是减慢了速度，除非操作员意识到需要更改该选项，否则没有任何好处。但调试起来可能非常困难，因为一切都很好，但在部署增长到某个时候，cinder 服务开始启动和关闭。此外，有充分的理由认为与任何其他服务共享 Ceph Cinder 卷存储池是操作员错误，不应该这样做。

普遍共识是应该进行此更改，并且我们应该将更改回溯（但附带一个发布说明，明确说明默认值正在更改以及该选项的作用）。

结论

  • 行动 - geguileo - 提出更改

复制金丝雀测试

Gorka (geguileo) 询问有多少人有使用复制的客户。在场的人都不确定。最近在 SolidFire 驱动程序中修复了一些复制错误，但这些错误是由开发团队发现的，客户没有报告。

目前 Dell (PowerMax) 和 NetApp (SolidFire) 正在进行复制测试，但都是手动测试。

Gorka 有兴趣拥有某种金丝雀测试，以便操作员可以针对实时安装进行测试并验证复制是否正常工作。他询问当前驱动程序是否可以支持这种测试，答案取决于测试是什么。例如，对 PowerMax 上的异步复制进行金丝雀测试将是困难的，因为所有使用该类型的卷都需要暂停同步，因此测试必须确保使用当前未被任何用户使用的卷。

另一个出现的问题是，需要审查和澄清复制文档。需要明确指出它取决于后端。我们还需要明确同步和异步复制之间的区别。

另一个复杂之处是，即使我们可以在 cinder 中实现金丝雀测试，但这并不能真正解决实际情况，在实际情况下，其他服务也会参与其中，并且必须确保无缝实施故障转移。

结论

  • 需要增强复制文档。
  • 最好对复制进行某种金丝雀测试，因为否则很难在配置正确且正常工作之前知道它是否正常工作。
  • 行动 - geguileo - 编写规范，提出复制金丝雀测试，团队可以确定规范的细节
  • 行动 - geguileo - 从长远来看，一旦我们在 Cinder 中有了一些东西，就与其他团队跟进，以便我们可以提出一个全局 OpenStack 解决方案

可用区和备份恢复的卷类型

这里有几件事正在发生

  1. 有一个规范悬而未决，用于为备份恢复添加 AZ 和卷类型规范 [0]。
  2. 与此同时，微版本 3.47 将支持添加到 create-volume API [1]，以便您可以从备份创建卷，同时指定卷类型和您想要的 AZ，因此规范变得有点多余。
  3. 最近，Jeremy Liu 提出了一种将 AZ 和卷类型规范添加到备份恢复调用中的实现 [3]。


Gorka 提出了问题：我们该如何处理 Jeremy 的补丁 [2]？

  • 我们可以接受该功能，但然后我们将拥有一个额外的代码路径，用于使用卷类型和 AZ 从备份创建卷
    • 但我们已经有两个路径了，并且此更改将只是使“恢复”路径与“创建”路径保持一致
    • 而且“恢复”路径并非仅用于将备份恢复到现有卷，而“创建”路径是正确创建新卷的方式；目前“恢复”路径也提供了创建新卷的选项
  • 拒绝该特性
    • 这不太好，因为规范已经搁置了一段时间，现在有人投入了很多精力在上面
    • 另一方面，我们不需要将此添加到 API 中；我们仍然可以在客户端模拟它（如果将 volume-type 或 AZ 传递给备份-恢复调用，客户端将实际调用“创建”API）


没有人对该怎么做有强烈的看法。Rajat 指出代码更改非常小——添加这个第二条路径所需的代码不多，所以看起来不会造成维护噩梦。而且 Gorka 说拒绝这个补丁在这个时候确实有点过分。

[0] https://blueprints.launchpad.net/cinder/+spec/availabilityzone-and-volumetype-for-backup-restore
[1] https://docs.openstack.org/api-ref/block-storage/v3/index.html#create-a-volume
[2] https://review.opendev.org/#/c/754925
[3] https://docs.openstack.org/api-ref/block-storage/v3/index.html#restore-a-backup

结论

  • 任何认为复制代码是一个大问题的人都需要在补丁上发表评论并提出这个观点。否则，我们将以正常方式继续审查补丁（即，使其能够合并）。
  • 行动 - rosmaita - 需要审查 Launchpad 中任何悬而未决的 BP，以避免再次发生这种情况
  • 行动 - rosmaita - 确保我们的贡献者文档和规范文档表明，处于“未目标化”或未在上一周期中实施的规范必须在当前周期重新提出

Cinder glance_store 在 cinder 后端为 NFS 时

这是一次与 Glance 团队的跨项目会议。问题是 cinder glance_store 在大多数情况下工作正常，但是当 cinder 后端为 NFS 时，会出现一些问题。

我不会总结整个讨论，只总结结论。如果您想获得完整的体验，可以观看录像

结论

  • cinder glance_store 驱动程序在 NFS 是 cinder 后端时，只能允许将卷存储为原始文件。这将允许 Glance 放入任何想要的内容，并且由于 Glance 使用不可变镜像数据，这些卷不需要支持高效快照，因为 Glance 永远不会请求该操作。

10 月 30 日星期五

录像

Cinder/PTG 业务

  • 所有 cinder 特定的截止日期都已添加到主要的 Wallaby 发布计划中：https://releases.openstack.org/wallaby/schedule.html
  • 在 Victoria 期间，midcycle-1 在规范冻结前 1 周举行，midcycle-2 在功能冻结和最终客户端库发布前 4 周举行。对于 Wallaby，这将是
    • midcycle-1：R-18（12 月 7 日那周）
    • midcycle-2：R-9（2 月 8 日那周）

midcycle 的格式将与过去两个周期相同，即为期两小时的视频会议。

第一个 midcycle 略微提前，因为规范冻结比 Victoria 提前一周，以考虑到冬季假期即将来临的审查带宽不足。

结论

  • 人们应该查看 Wallaby 计划中的 cinder 日期，以验证它们是否合理
  • 人们应该查看建议的 midcycle 日期，并指出是否存在冲突
    • 12 月 7 日至 8 日是西班牙的假期，所以如果我们想坚持那一周，我们可能要选择星期三或星期四（星期五传统上不受 midcycle 欢迎）

从 os-brick 中删除已弃用的加密器

弃用是在 Ocata 中。Lee Yarwood 已经发布了 brick、cinder 和 nova 的补丁，但他有一个问题，即我们是否需要进行在线迁移，以便相应地调整现有的加密卷类型。


共识是应该在 cinder 中添加一个升级检查，以验证迁移是否会成功，以及实际的迁移。这应该包含在 cinder 补丁中。

有可能删除对旧名称的支持可能会破坏 heat、python-openstackclient、tempest、patrole 或 rally，所以我们需要检查这一点并提交对受影响项目的补丁。Hound 可用于查找用法：http://codesearch.openstack.org/?q=LuksEncryptor&i=nope&files=&repos=

结论

  • 行动 - rosmaita - 对补丁留下反馈
  • 行动 - 任何感兴趣的人 - 对受影响项目的补丁

改进服务宕机

这是 Gorka (geguileo) 贡献的另一个主题。

目前，如果驱动程序无法初始化或服务无法连接到数据库，则卷服务似乎已宕机。但还有其他相关情况，例如，如果服务无法连接到后端。

我们需要实现这个功能吗？如果我们可以为每个服务提供单独的信息，那就太好了。驱动程序可以传递有关失败内容的信息。也可以传递有关降级状态的信息，例如，存储阵列已启动，但需要一些干预。

对于未实现我们所需内容的驱动程序，我们可以假装一切正常。或者我们可以尝试进行某种通用实现，检查在过去 X 分钟/小时内有多少请求失败，并将节点标记为降级，并存储有关标记原因的消息。或者我们可以告诉操作员，对于未为 Cinder 实现此功能的驱动程序，他们应该使用外部监控工具。

复制状态可以通过特定字段处理，也可以包含在有关阵列的常规健康信息中。

我们可能希望管理器定期（频率可配置）调用驱动程序以检查状态。状态检查应该对驱动程序端来说是轻量级的，这样就不会干扰正常操作。

结论

  • 这是一个有趣的想法。一旦完善，我们可以看看是否有供应商有兴趣实现这个功能。
  • 行动 - gegulieo - 编写一个概述这个想法的规范

新的规范（以及其他搁置了一段时间的东西）

“volume list 查询优化”

这个规范和补丁都有。它实际上是一组错误，所以规范应该被拒绝，我们可以专注于补丁。


我们正在寻找的是可回溯的错误修复，以及文档更新，以确保所有面向用户的文档仅提及“官方”卷状态，并且贡献者文档解释了这些“额外”状态仅供内部使用（并且我们应该尽力不要再做这种事情）。

在审查中需要注意的另一件事是，我们应该在其中一些情况下创建用户消息。这应该很容易实现，因为虽然我们显示 ERROR，但我们有内部状态可用，并且可以使用它来填充用户消息。

结论
  • 行动 - rosmaita - 拒绝规范并附上适当的解释性评论
  • 行动 - 所有人 - 考虑上述因素审查错误修复

关于同一主题的两个提出的规范（相互确保毁灭）

这个主题之前已经出现过，所以我们应该更新某个地方的文档来解决这个问题。规范是


Eric 指出，这两个规范都没有明确说明他们正在解决的威胁模型，并且一旦写出威胁模型，就显而易见，我们无法在 Cinder 端做任何事情。Sean 指出在其中一个补丁中，我们的期望是供应商知道他们的产品正在多租户环境中被使用，并且他们采取适当的步骤来确保新的卷中没有旧数据。

此外，最终用户无法在删除卷之前清零卷，因为（取决于使用的存储技术）这可能无法消除后端中所有用户数据的痕迹（即使供应商保证每个新卷都是“新鲜的”）。因此，如果威胁模型是有人窃取物理阵列并恢复您的数据，Cinder 无法保护免受此类攻击。Cinder 的关注点是 OpenStack 用户之间没有数据泄露。操作员需要咨询存储供应商以解决 Cinder 无法控制的这些问题。

担心物理阵列中留下数据痕迹的用户应考虑使用加密卷。

结论
  • 行动 - geguileo - 自愿更新驱动程序删除方法，以提及驱动程序不能提供带有数据的卷，可能使用 doc/source/contributor/drivers.rst 的“安全要求”部分中的文本
  • 行动 - rosmaita - 验证两个规范是否为 -2

离题：弃用厚配置 LVM？

默认值一段时间以来一直是薄配置（自 Change-Id: If25e814eb6282fef9a1dd30d17c80eab6860e275 in Ocata 以来的时间），我们相信每个人都在使用薄配置。如果只支持薄配置，我们可以删除 LVM 驱动程序中的许多兼容性代码。

结论
  • 我们应该在 Wallaby 中弃用厚配置 LVM，以便在 X 中删除。
  • 行动 - eharney - 发布弃用补丁

支持将任何快照还原到卷

Cinder 团队继续支持这个提案，但需要解决几个问题

  • 如何处理通用（非后端辅助）回滚的性能问题；如果它会对部署造成问题，操作员不应该启用它
  • 对预期的行为有一些疑问。例如，如果您有 10 个快照的链，并回滚到 3，如果您做一些事情然后回滚到 7，会发生什么？这是否会在所有后端上按预期工作？
  • 这将把我们的快照模型从线性变为树形
    • 这会对可以删除的内容产生什么影响？
    • 用户需要看到树形结构吗？
      • 可能不需要最终用户，但驱动程序和管理员可能需要访问此信息
      • 顺便说一句：vmware 可能会显示树形结构
    • 我们（Cinder）仍然期望可以独立删除快照
      • 树形模型是否引入了阻止这种情况的快照之间的关系？
  • 可以接受某些回滚可以执行而某些回滚不能执行
    • REST API 将向驱动程序发出同步调用，以确定是否允许特定的回滚，以便我们可以在初始响应中拒绝此类请求。
      • 如果驱动程序说可以，但稍后由于其他原因失败，我们希望用户收到事件消息
      • 需要找到一种方法将这个 can-i-revert 信息传递到驱动程序并返回
  • 我们需要一些场景和测试建议，以便驱动程序维护者可以确定这是否适用于他们支持的后端
结论
  • 我们需要一些场景和测试建议，以便驱动程序维护者可以确定所提出的内容是否适用于他们支持的后端
  • 行动 - rosmaita - 在规范上留下评论，要求作者解决上述问题

后端功能

团队一致认为我们继续认为这个规范是一个好主意：https://review.opendev.org/#/c/655939/

Eric 没有时间处理它，所以他愿意让别人接手。出现了一些新问题

  • 即使驱动程序支持某个功能，后端也可能没有启用它
  • 对于某些功能，驱动程序有特定的名称，所以需要解决这个问题
结论
  • 这对操作员非常有帮助，希望有人会接手

将 md5 替换为 oslo 版本

Ade Lee 有一个补丁：https://review.opendev.org/#/c/753848/

虽然上游 python 正在弄清楚如何在非安全上下文中处理 md5 的使用，但 OpenStack oslo 正在向 oslo_utils 添加一个封装，其中包含一个“usedforsecurity”参数。Ade 的补丁将 cinder 中 hashlib.md5() 的使用更改为 oslo_utils 版本。他在提交消息中留下了注释，说明 md5 似乎实际上正在安全上下文中被使用。

结论
  • 行动 - rosmaita - 更新 contrib 文档，提醒驱动程序维护者不要使用 MD5
  • 行动 - rosmaita - 联系当前驱动程序维护者，了解是否在安全上下文中使用了 MD5
  • 行动 - rosmaita - 确保明确告知驱动程序应使用标准的加密库，而不是自行实现加密代码（在驱动程序 contrib 文档和驱动程序审查指南中）

如何测试优化的 glance-cinder 镜像-卷工作流？

这个问题源于处理一个 bug 的过程，该 bug 似乎并没有导致任何故障，只是阻止了一些优化。当 Glance 使用 Cinder 作为后端时，它的镜像已经位于 Cinder 后端，每个镜像对应一个卷。如果有人想从镜像启动，Cinder 可以直接克隆包含镜像的卷到一个新的卷，这比从 Glance 下载并把数据写入卷要快得多。

Glance 刚刚更改了它使用的 location URI 的格式，因此该 bug 是 Cinder 无法读取新的 URI，因此无法找到包含镜像的卷。但这并不会破坏 Cinder；当找不到卷时，Cinder 会回退并使用较慢的代码路径来获取镜像数据到新的卷。我正在尝试寻找一种自动化的方法来验证是否正在使用优化的工作流。

结论
  • 也许添加一些遥测信息来记录优化操作的数量等。
  • 添加文档，解释在日志中查找什么内容，以验证 cinder 和 glance 是否已正确配置以使用此功能

团队角色 & 业务

当前角色

当前角色在该补丁中解释，以更新“发布周期任务”文档：https://review.opendev.org/#/c/759782/

提议

  • bug 代理 (neutron 这样做) - 关注收到的 bug，确保正确标记，并在每周会议上报告以获得帮助进行分类
  • 发布经理 - 组织稳定的发布
  • 第三方 CI 联络人 - 在每周会议上报告各种 CI 的运行情况
    • 第三方 CI 工作组 - 如果 CI 维护者有兴趣联合起来更新 CI

战术 (短期)

  • v2 API 移除负责人/经理/无论什么
    • nova, glance, horizon, heat, osc -- 验证它们是否正在使用 v3 API
    • devstack 默认是 v3 api，tempest 也默认使用 v3
      • 它们可能仍然有一些硬编码的东西，期望 v2 API 可用
    • 确保在宣布此消息的电子邮件中包含 [interop]
    • 如何处理 python-cinderclient？
  • alembic 迁移协调员
    • Stephen Finucane 本周期正在为 nova 和 glance 执行此操作，现在是时候为 Cinder 完成此操作了

Wallaby PTG 反馈

要么到本周这个时候每个人都筋疲力尽，无法抱怨，要么一切顺利，没有改进的空间。

唯一的回复是针对提示“主题的“宽松”安排是否有效，或者我们应该进行特定时间安排？”，建议是“也许我们可以在不同的主题上添加一个“ping 我”部分，当我们即将开始主题时，ping 感兴趣的人？”这似乎是一个容易实现并且可能有帮助的事情。

结论

  • 如果你对这些角色中的任何一个感兴趣（或者对可以帮助 Cinder 项目的其他角色有任何想法），请与 rosmaita 联系
  • Michael McAleer 志愿担任 Bug 代理
  • Ivan Kolodyazhny (e0ne) 志愿担任 v2 API 移除协调员
  • 行动 - rosmaita - 确定应该继续支持 v2 多久（写出选项并在即将到来的 cinder 会议上讨论）
  • 行动 - 任何人！ - 记住将“ping 我”部分的想法放入下一个 PTG 规划 etherpad

后期主题

attachments API - 暴露连接信息

Rajat 要求对 https://review.opendev.org/#/c/713231/ 提供一些反馈，该反馈解决了 Bug #1736773，其中 Attachments API 可能会在 GET 响应中暴露过多信息。问题是，虽然仅使用卷的 Nova 用户可能不需要看到此信息，但其他用途需要连接信息，以便可以连接到卷。例如，如果你正在运行 Kubernetes 并想要访问 cinder 卷，则需要此信息。

Gorka 建议也许可以有两个策略，一个只显示 Kubernetes 案例需要的内容（假设它不需要响应中的所有内容），另一个允许完全访问，然后操作员可以限制云中连接信息的可见性，只对需要它的人可见。

结论
  • 行动 - geguileo - 查看 Cinder-CSI，了解它需要哪些确切的连接信息，然后审查补丁

保持连接信息最新

Lee Yarwood (lyarwood) 一直在推动一个 idempotent initialize_connection 标志的想法，这样 Nova 就会知道它是否可以在不创建新的附件的情况下获取更新的连接信息。Lee 仍在努力，并将与 nova 团队讨论：https://review.opendev.org/#/q/topic:bug/1860913

cinder attach/detach 服务

有人在 etherpad 上提到，他们在峰会上讨论过添加一个新服务，该服务可以接受调用以使用 os-brick 附加/分离卷。不幸的是，那个人在 Cinder PTG 上讨论该主题时不在场。

如果他们仍然想讨论它

autospeccing mocks

Eric (eharney) 在其中一个 midcycle 会议（或上一次 PTG）上提出了这个问题，并且它再次浮出水面：https://review.opendev.org/#/c/760301/

只是在编写或审查单元测试时需要注意的事情……

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