跳转到： 导航, 搜索

CinderYogaPTGSummary

简介

此页面包含在 Yoga 开发周期中，于 2021 年 10 月 18 日至 22 日举行的项目团队会议期间，Cinder 项目会议所涵盖主题的摘要。Cinder 项目团队从 10 月 19 日星期二到 10 月 22 日星期五，每天会面 4 小时（UTC 1300-1700）。

Cinder 团队在 Yoga（虚拟）PTG，2021 年 10 月的子集。


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


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

星期二 10月19日

录像

问候，用户调查讨论

对于尚未参加的人来说，这是 cinder 团队在 PTG 上工作的方式

  • 会议已录制
  • 请在 etherpad 的“与会者”部分为每天签到
  • 所有注释、问题等都发生在 etherpad 中；请记住在您的评论前加上您的 IRC 昵称
  • 所有在场的人都可以在 etherpad 中评论或提问
  • 此外，所有在场的人都应随时在任何讨论期间提问或发表评论
  • 我们按照 etherpad 中列出的顺序讨论主题，并根据持续时间较长或较短的会议进行调整
  • 我们坚持跨项目会议的计划时间，但对于其他所有内容，我们都比较灵活


接下来，我们查看了最新用户调查的项目特定反馈回复。这是一个 ethercalc，组织起来更容易查看 cinder 相关的回复：https://ethercalc.openstack.org/=2021-user-survey

我们在调查中的问题是：“如果您希望更改（添加、删除、修复）Cinder 的一件事，那会是什么？”

我们收到了 39 个回复（在约 425 个调查回复中）。

在查看回复时，有一些我们已经拥有的功能请求，还有一些我们不理解的评论。我们决定向邮件列表发送回复，提及已实现的功能，并开始讨论我们不理解的项目。（调查回复是匿名的，因此我们无法直接联系操作员。）Amy Marrich（spotz，她负责操作员会议）提到操作员倾向于关注 meetup twitter 帐户，因此联系操作员的好方法是在 ML 上发布，然后通知她从 ops meetup 帐户发布链接。

定量的回复（例如，包含 cinder 的部署数量）在 OpenStack 分析页面上：https://openstack.org/analytics/

对用户调查团队的一些反馈

  • 网站报告中的数据很难消费（它显示在不可调整大小的图形中，并且很难区分“感兴趣”、“测试”和“生产”的百分比）。可以选择下载为 PDF，但它会给你相同的不可调整大小的图形。能够将数据下载为 CSV 文件会很有帮助。
  • 在下一次调查中，我们想添加问题：您正在使用哪些驱动程序来配置您的 Cinder 环境？
  • 我们喜欢我们当前的问题，但很多答案都太模糊了——您有什么建议可以指示人们应该清晰具体吗？

结论

  • 操作 (rosmaita)：启动一个 etherpad 用于回复操作员
  • 操作 (rosmaita)：将我们的反馈传达给用户调查团队

正在进行的镜像加密更新

Josephine Seifert (Luzi) 向我们更新了镜像加密工作的状态。当前计划是拥有“无秘密消费者”的实验性镜像加密。原因是允许对镜像加密工作进行编码和审查（并设置 CI），同时等待秘密消费者 API。（Barbican 中的秘密消费者 API 将允许服务注册一个秘密正在使用中（尽管秘密所有者仍然可以使用 --force 标志删除它）。延迟是 microversioning 需要引入 Barbican API 才能添加新的 API。）

当前的想法是将此作为实验性功能发布，并在准备好秘密消费者 API 时“正式”发布。此策略在 Glance spec-lite 中描述：https://review.opendev.org/c/openstack/glance-specs/+/792134/

cinder 团队需要什么才能完成这项工作

  • os-brick -- 将拥有服务使用的 PGP 加密代码。补丁可供审查：https://review.opendev.org/709432
  • cinder -- 从 glance 下载镜像需要解密这些镜像以将其写入卷
  • cinder -- 上传卷到镜像（也许？需要检查规范）
  • cinder -- 还需要在可用时使用秘密消费者（如果 cinder 在上传时进行加密）
    • 也可能希望将秘密注册添加到我们当前的 luks 加密卷代码中，以保护加密密钥 ID
  • glance cinder 后端呢？
    • 我们有一个优化的路径，它会克隆而不是下载和复制到卷上
    • 需要处理这种情况
  • 镜像-卷缓存呢？
    • 这些东西不应该包含在缓存中吗？
    • 需要查看规范中对此的说明


当前的 cinder 规范是：https://specs.openstack.org/openstack/cinder-specs/specs/xena/image-encryption.html

还没有 cinder 的更改补丁，但有一个带有秘密消费者占位符的 glance PoC 补丁：https://review.opendev.org/c/openstack/glance/+/705445

结论

  • 操作 (rosmaita) 再次查看 cinder 规范。它在 Train 中获得批准，并且从那时起就没有人看过。
  • 操作 (cinder 团队) 感兴趣的各方也应该再次查看规范。
  • 操作 (whoami-rajat) 再次查看规范，特别是考虑到 cinder glance_store 的情况。
  • 操作 (Luzi) Gorka 指出，如果提供了一些 cinder POC 补丁，则更容易审查
    • cinder 补丁（待定？）
    • cinder-spec（完成）
    • os-brick 补丁（准备就绪）
    • glance 补丁（准备就绪）

支持静默快照/备份

Arthur Outhenin-Chalandre (Mr_Freezeex) 想要支持静默卷，用于备份或快照，并跟进了一些以前的提案


netapp/vmware 卷驱动程序已经支持在没有 nova 调用的情况下静默快照，并且可以将其扩展到其他驱动程序。

讨论中提出的一些要点是

  • 一致性组：只给你崩溃一致性，与 cinder 端制作的当前常规快照相同。如果崩溃一致性是人们所需要的，那么这个提案是不必要的
  • 问题：这应该如何处理附加到实例的多个卷？
  • 通用组允许任意分组卷，这将如何影响它们？
  • cinder 是此请求的正确入口点吗？
  • Simon 提到静默整个 VM 对于拍摄快照来说是过度的（并且可能存在风险），特别是如果大多数人已经设置好处理崩溃一致性快照。
  • Gorka 指出我们需要考虑一些更广泛的用例并决定是否需要解决它们，例如
    • 单个卷：具有静默的快照（简单情况）
    • 单个 VM 中的所有卷
      • 属于同一组（通用或一致性）
      • 是独立的卷（包括引导卷）
    • 组中的所有卷（可以附加到不同的 VM）
    • 多重附加（单个卷附加到多个 VM）


实现不必处理所有上述情况（并且可能还有一些其他的用例会出现），但我们希望清楚地了解正在解决哪些用例以及我们不打算处理哪些用例。

结论

  • 操作 (Mr_Freexeex) 将提出解决上述问题的规范

默认类型回顾

Rajat Dhasmana (whoami-rajat) 领导了关于我们目前在默认卷类型方面所处位置的讨论。这是他的幻灯片，如果您想跟进：https://docs.google.com/presentation/d/1qEI3PApyzYWBnoUUTOnxR8zQlI1s3YwNjt5CZqHVuSA/edit?usp=sharing

在 Train 中，我们决定 cinder 不允许使用未类型的卷（代码中存在一些地方，尤其是在某些驱动程序中，假定了一个卷类型，如果不存在，就会发生坏事）。因此，为了解决这个问题，Train 版本中引入了一个 __DEFAULT__ 类型（一个非常小的类型，基本上只是名称、id 和描述），以保证每个部署中至少有一个卷类型，并将所有未类型的卷分配到数据库中的此类型。此外，如果未设置 default_volume_type cinder 选项，则将使用 __DEFAULT__ 类型。

一个问题是，有些部署工具（和操作员）已经创建并设置了 default_volume_type，操作员报告说，当他们在 volume-type-list 响应中看到 __DEFAULT__ 时，用户感到困惑，并且会显式创建类型为 __DEFAULT__ 的卷，这不是操作员想要的，他们希望用户简单地使用配置的默认类型。问题在于 __DEFAULT__ 类型无法删除（因为它的目的是确保部署中始终存在某种卷类型）。

后来我们重做了这个逻辑（并将其回移植到 Train），使得 cinder 选项 default_volume_type 是必需的（默认值为 __DEFAULT__），并且 cinder 不允许删除 default_volume_type 的值为的卷类型（当它是默认值时），并且始终至少存在一个卷类型。因此，操作员可以将 __DEFAULT__ 类型视为任何其他类型（例如，如果该类型没有现有的卷，则可以删除它）。

然而，__DEFAULT__ 默认情况下仍然存在，并且正在给那些不想使用它或对其来说不必要的部署带来困惑。

我们对此进行了一些讨论，并得出结论，决定如何处理特定部署中的 __DEFAULT__ 卷类型是部署的责任。

但我们仍然可以在 cinder 端做一些事情来改善这种情况

  • 确保在操作员文档中明确说明我们已经有了避免创建无类型卷的机制，因此如果不再使用 __DEFAULT__，可以将其删除。（我们选择它的名称是为了避免与任何现有的卷类型冲突，但 "__DEFAULT__" 看起来很正式且吓人，可能会导致操作员认为它对于 cinder 的正确运行是必要的。）
    • 将此信息添加到操作员配置文档的某个位置
  • 在 victoria 中，cinder 引入了每个项目的默认类型： https://specs.openstack.org/openstack/cinder-specs/specs/victoria/default-volume-type-overrides.html。我们需要推广这样的想法：如果用户想查看有效的默认卷类型，他们需要发出 GET /v3/{project_id}/types/default API 调用，而不是查看 volume-type-list 并尝试从名称或描述中找出它。我们可以改进文档以推广此调用
    • 升级 API-REF
      • 在 volume-create 部分添加一些内容
      • 可能也在类型列表中
    • 升级客户端帮助信息吗？
      • 查看 volume-create 帮助文本，添加一些内容
    • 在安装文档中，说明默认类型配置的重要性，以及 __DEFAULT__ 类型可以（并且应该）在启动后默认值已在 cinder.conf 中创建并设置后被删除（由操作员/部署工具）。
  • Gorka 建议我们也许可以引入一个微版本，以某种方式突出显示你在发出 volume-type-list 请求时有效的默认卷类型
    • horizon 可能已经在做类似的事情（“类似的事情”意味着突出显示默认卷类型）？无论如何，我们也应该这样做。

结论

行动 (rosmaita) 确保人们跟进这件事……我们收到了一些关于小功能和文档工作的咨询，这些来自各个社区成员，这将是这些人的理想选择

驱动程序支持矩阵更新

这是一个参与性活动。这个想法（在过去的 PTG 中多次提出）是我们需要审查支持矩阵的内容。其中列出的功能实际上并不是驱动程序不支持时“缺失”的，并且可能有一些有用的功能没有指定。我们对此进行了很多讨论，让我们坐下来做吧。

支持矩阵的目的是在选择后端时对操作员有用。目前它的样子是： https://docs.openstack.org/cinder/latest/reference/support-matrix.html

团队在 etherpad 上做了一些笔记，你可以在那里看到完整的讨论： https://etherpad.opendev.org/p/yoga-cinder-support-matrix

结论

  • 如果我们将列和行互换，它会更容易阅读。Chuck 做了一个快速模拟，并且很明显他是对的。我们有一些自定义的 python sphinx 代码从 RST 和配置文件生成矩阵，因此必须在我们的自定义代码中进行更改。
  • 行动 (rosmaita)：更新关于没有正常工作的 CI 的驱动程序会发生什么情况的说明。它不再准确。
  • 开放问题：我们是否应该指出与功能相关的微版本？例如，[operation.online_extend_support] 与微版本 3.42 相关，我们是否应该在支持矩阵中提及它？
  • 看起来最近的 gerrit 升级破坏了监控我们 CI 统计信息的脚本： http://cinderstats.ivehearditbothways.com/cireport.txt
    • 行动 (jungleboyj)：跟进 Sean，看看他是否可以修复它，以及他是否计划继续维护它。
  • 行动 (rosmaita)：更新 cinder 基本功能列表

互操作性！

计划与互操作性工作组会面，以向商标指南中添加功能。

一些链接提醒我们有什么问题


互操作性工作组的代表延迟了，然后不得不离开，但留下了这些请求

  • 审查并评论 https://review.opendev.org/c/openinfra/interop/+/811049/3/guidelines/2021.11.json 的 volume/cinder 部分，并确定这些是否仍然需要，是否存在一些已知的 issues 或 tempest 更改以覆盖
  • Wallaby 和 Xena 周期中添加的新功能和测试是什么，以便我们可以考虑将其用于未来的指南？
  • 对于当前指南未覆盖但已达到成熟度和客户使用的功能，您的建议是什么？
  • 最后，cinder 希望如何处理微版本？目前我们覆盖互操作性 API 版本 3.0。每个发布支持的 API 微版本范围是多少？然后我们可以定义这些的重叠，用于最新的 3 个版本 + 更多未来的版本，我们可以声称每个云实现都必须支持。

结论

  • 我们仍然可以使用互操作性工作组的输入来满足上述请求。
  • 行动 (rosmaita)：联系互操作性工作组，并邀请他们参加即将举行的 cinder 会议

社区目标和“安全且一致的 RBAC”工作

在会议开始时，看起来我们已经计划好了一切


但是，Dan Smith 和 Lance Bragstad 参加了会议，并向我们介绍了当前的讨论

  • 跨项目存在一个持续的问题，即滥用系统范围来允许管理员在项目内执行操作
    • 系统-* 角色不应允许在项目内执行操作
    • 系统范围的操作范围是系统（并且必须尊重项目边界）
  • 系统范围允许你操作系统资源（例如，服务、集群、卷类型）
  • 项目范围允许你操作项目资源（例如，卷、快照、备份）
    • 示例：系统-* 角色可以与卷类型交互（CRUD），但不能使用它们来创建卷（因为卷是项目资源）* 只有项目-* 角色才能在项目内操作
  • 计划依靠从更高层级域的继承来创建一个可以在单个项目内操作而无需“位于”这些项目中的角色


我们继续在这里讨论： https://etherpad.opendev.org/p/cinder-yoga-secure-rbac-more-thoughts

结论

行动 (rosmaita, abishop)：跟进以了解正在发生什么

10 月 20 日星期三

录像

os-brick 用于 NVMe - 下一步

Simon Dodsley (simondodsley) 更新了对扩展 os-brick 中 NVMe 支持感兴趣的工作组。目前，Pure、Kioxia 和 Dell/EMC 都对这项技术感兴趣，并正在进行支持。我们正在收集信息和想法： https://docs.google.com/document/d/1_xXgYOElC5G8RawWyEEHKOF1A5E3RmtlUlmcqCtuUzA/

如果你无法访问文档，请在 IRC 中 ping simondodsley。任何对 NVMe 感兴趣的人都可以参与这项工作。

Gorka 提出了两个补丁，以便我们可以使用 LVM 进行测试。这些使用 NVMe 工具/协议导出 LVM 卷，使用 NVMe 代替 iSCSI 来使卷可用。这样我们就可以独立于 NVMe 解决方案供应商进行测试，因为他们仍在建立他们的第三方 CI 系统（由于 covid-19 导致网络卡出现问题）


讨论中出现的一件事是，在审查 os-brick 补丁时，没有明确的方法来知道正在使用哪个连接器。通常可以从 CI 名称中看出正在使用哪个 cinder 驱动程序，但连接器并不明显。过去，nvmeof 连接器存在这个问题，不清楚哪些第三方 CI 结果应该全部通过以表明连接器正在工作。Gorka 建议我们创建一个 os-brick 连接器和测试它们的 CI 的审查员图表（包括描述变体，例如，iSCSI 共享目标、iSCSI 独立目标）。也可能要求 os-brick CI 作业在其名称中添加它们正在使用的连接器。

这引发了关于我们想在 Yoga 周期中在 os-brick 中完成什么的一般讨论

请注意，上述两项工作都不会影响主线 os-brick 代码，因此对于不使用它们的人来说风险非常低。

结论

  • 提醒：要包含在 os-brick 库的 Yoga 版本中的更改必须在 2022 年 2 月 10 日星期四 20:00 UTC 之前合并
  • 行动：创建 os-brick 连接器和测试它们的 CI 的审查员图表

澄清卷驱动程序 API，第一部分

这是一次参与性活动。在过去几次 PTG 中，我们都同意，如果 cinder 项目团队能够更清楚地指定驱动程序需要实现的接口，将有助于驱动程序贡献者。我们已经有了一些工具来确保实现特定的功能，但有些情况下，描述语义甚至期望返回的内容的文档要么过时，要么不完整。每个人都同意这是一个好主意，所以我们决定在 PTG 上进行一次工作会议来讨论这个问题，并敲定一些内容，而不是等待别人来启动它。

我们的想法是从今天开始，并在周五跟进。会议记录在这里：https://etherpad.opendev.org/p/yoga-volume-driver-API

周五的会议被取消了，以便我们能够参加关于 Yoga 社区目标（“安全且一致的 RBAC”）的 TC 会议。

结论

  • 讨论富有成效，我们立即确定了应该删除的两个函数。我们将继续将此作为整个周期中的一项持续活动，也许作为“本周的卷驱动器 API 函数”，并逐步记录整个接口。

欢乐时光和吉祥物/团队名称讨论

我们移至 meetpad 进行此讨论，因为它不需要录制。

Simon Dodsley (simondodsley) 带领我们讨论了 cinder 吉祥物和 cinder 团队的命名。您可以在 etherpad 上查看建议和投票：https://etherpad.opendev.org/p/cinder-yoga-happy-hour

结论

10 月 21 日星期四

录像

优化从 qcow2 镜像创建可启动卷 [cinder 后端]

Rajat Dhasmana (whoami-rajat) 讨论了他正在进行的一个 WIP 补丁，以优化从 Glance 存储在 cinder glance_store 中的镜像创建可启动卷的路径：https://review.opendev.org/c/openstack/cinder/+/805949

当前的工作流程大致如下

  • 将镜像卷附加到 glance 主机
  • 将新卷附加到 cinder 主机
  • 从 glance 复制数据到 cinder


新的工作流程将是

  • 将镜像卷和新卷都附加到 cinder 主机
  • 在它们之间复制数据


出现的一个问题是，这种优化能带来多少性能提升并不明显。

在讨论过程中，另一个可能的性能提升出现了。如果 cinder 知道镜像的虚拟大小，它可以直接转换为目标，而无需使用会填满的 image_conversion_dir。（这对于某些驱动程序（例如，RBD）可能不可行，因为它实际上不在 /dev 下呈现卷，但如果它避免了转换目录空间问题，这是值得研究的，因为这个问题似乎经常发生）。

结论

  • action (whoami-rajat)：将研究他想要获得的性能提升量

删除用户消息中的异常映射？

简而言之，cinder 有很多 API 调用返回 202（已接受），但仍然可能失败。您最终会得到一个处于错误状态的卷，并想知道发生了什么。用户消息 API 允许开发人员生成包含一些信息的消息，最终用户可以理解并可能提供给支持人员以进行进一步的故障排除。为了确保不应暴露给最终用户的部署细节不被泄露，您必须为 Action 和 Detail 指定一个预定义的字段，这些字段将显示在对最终用户的响应中。

有关此功能的完整信息可以在 cinder 开发人员文档中找到：https://docs.openstack.org/cinder/latest/contributor/user_messages.html

本次讨论的主题是代码中的一条注释：“同时，使用异常到 Detail 的映射来减少 cinder 任务代码中事件分类的工作量。” https://github.com/openstack/cinder/blob/master/cinder/message/message_field.py#L20-L21

最初的异常映射想法听起来不错，但实际上却并不好。首先，它有点令人困惑，如开发人员文档中所述：https://docs.openstack.org/cinder/latest/contributor/user_messages.html#cinder-exception-in-context

如果您传递一个异常 *AND* 一个 Detail，如果异常在映射中，您的 Detail 将被忽略，并将使用映射的 Detail。我们不希望人们只传递一个异常，因为如果它不在映射中，结果将是一个无用的“未知错误”Detail 消息。但是，如果异常可能在多个地方引发，映射的 Detail 将会有点通用。在某些情况下，您可能确切知道 Detail 消息应该是什么，因此您需要 *不* 传递异常（或者您的更精确的 Detail 将不会被使用）。但在其他情况下，使用映射可能很好。

您可以在此审查中查看一些示例：https://review.opendev.org/c/openstack/cinder/+/786627/19

我认为 Gorka 提出了一个很好的观点，我们希望鼓励人们传递异常，因为在某个时候，我们可能希望管理员在用户消息响应中看到比普通最终用户更多的信息，这些额外信息将从异常中填充。但当前异常映射的工作方式会阻止开发人员在知道应该使用哪个 Detail 的情况下传递异常。

所以问题是：我们是否要删除异常映射？

结论

  • 共识是，我们应该保留映射，但引入一个新的参数来允许开发人员指定是优先使用传递的 Detail（新行为）还是映射的 Detail（旧行为）。
  • action (rosmaita)：为此提出一个补丁
  • 此外，我们希望在所有情况下都传递异常，以便可以在某个时候增强用户消息响应以供管理员使用。
  • action (rosmaita)：提出一个后续补丁，将异常添加回 message_create 调用

完成 sqlalchemy-migrate -> alembic 迁移

Cinder 项目非常幸运，Stephen Finucane (stephenfin)（您会认出他的名字来自 nova、openstackdocstheme、一堆 oslo 库以及其他一些东西）在 Xena 周期中成为了 Cinder 的英雄，并帮助我们解决了大量技术债务，从而摆脱了使用不再受支持的 sqlalchemy-migrate，并转向了 alembic（除了受支持之外，它还有很多不错的功能）。Stephen 给了我们一个快速更新，关于这将会如何进行以及我们需要在 Yoga 中做什么来完成过渡。

首先，您可以在这里找到补丁：https://review.opendev.org/q/topic:%2522bp/remove-sqlalchemy-migrate%2522+(status:open+OR+status:merged)+project:openstack/cinder

在将我们的 sqlalchemy-migrate 迁移转换为 alembic 时，我们的模型和迁移系列结果之间出现了一些差距。Stephen 有一些补丁来解决这些问题，并添加了测试（基于 oslo.db 提供的东西）以防止将来出现回归：https://review.opendev.org/c/openstack/cinder/+/813223

Stephen 指出 SQLAlchemy 2.0 是一个破坏性更改。1.4（我们现在正在使用）中有 *很多* 弃用，需要在我们开始使用 2.0 之前解决。其中一些正在 oslo_db 中完成，但有些需要在 cinder 中完成。（我们可以将一些 nova 更改作为模型。）此外，sqlalchemy-migrate 与 2.0 不兼容，因此在 openstack 转换为 SQLAlchemy 2.0 时，必须完成 alembic 的过渡。

对于需要在 Yoga 中编写新迁移的 cinder 开发人员，Stephen 说 alembic 文档非常好，我们可以使用初始迁移作为示例。与 sqlalchemy-migrate 的一个主要区别是，alembic 不依赖于文件名约定来排序；而是维护迁移文件中的元数据。元数据的示例在这里：https://github.com/openstack/cinder/blob/master/cinder/db/migrations/versions/921e1a36b076_initial.py#L13-L18

要生成一个新的迁移文件，您可以使用 alembic，尽管 Stephen 有一个补丁显示如何使用 tox 来执行此操作。

总的文档如下

结论

与 Glance 团队的跨项目会议

Glance PTG etherpad 在这里：https://etherpad.opendev.org/p/yoga-glance-ptg

优化将卷上传到 RBD 后端的镜像

Rajat Dhasmana (whoami-rajat) 讨论了当我们将卷作为镜像上传到 glance 的 rbd 后端时，它会从 0 大小的 rbd 镜像开始，并以 8 MB 的块执行调整大小，这使得操作非常慢。当前的思路是将卷大小作为镜像大小传递，以避免这些调整大小操作。

为此，cinder 需要知道要将镜像放入的存储是 RBD。在 Glance 侧，存储的后端细节不应暴露给最终用户（就像 cinder 不向最终用户暴露后端细节一样）。也许使用服务令牌来获取此信息？我们需要一种安全的方式来获取此信息。

一个问题是 Glance 目前不识别服务令牌，因此需要添加此支持。此外，还有一个关于安全 RBAC 工作如何影响使用服务令牌的更一般问题（我们不知道）。

另一个与此 RBD Glance 快捷方式相关的问题（也出现在 nova 使用 ceph 时）是 Glance 没有这种镜像的多哈希属性。因此，在工作流程中包含校验和验证的用户无法使用这些镜像。

我们可以通过允许在 cinder 中关闭此优化来处理安全/性能权衡。它会更慢，但您将获得用于后续验证的多哈希属性。

结论
  • action (whoami-rajat) 根据此讨论修改 cinder 规范
  • action (whoami-rajat) 添加 Glance 规范中的 Stores API 更改

当 Glance 后端是 cinder 时的上传卷到镜像优化问题

Rajat Dhasmana (whoami-rajat) 讨论了当 Glance 后端是 cinder 并且我们将卷上传到镜像时，存在一种优化，它将卷克隆为镜像卷并在 Glance 中注册位置。如果将卷克隆到与 Glance 默认后端（例如 cinder-lvm）不同的后端（例如 RBD），则会导致问题。讨论的当前解决方案是将卷类型作为 Glance 元数据传递，并在 Glance 侧进行比较以通过或失败操作。

结论
  • 如果我们将存储类型从 Glance API 暴露出来，我们可以查询默认存储并相应地执行优化（或不执行），因为此方案具有与先前提案相同的性能/安全权衡。因此，我们可以使用相同的 Glance API 更改和 cinder 配置选项来控制优化。

一般讨论

  • Glance 中的虚拟大小怎么样？
    • glance 读取镜像标头并从中提取虚拟大小并填充它（可能并非所有格式都如此）
    • 虚拟大小是 Glance 中的只读属性（无法通过 API 修改，必须由 Glance 设置）
  • 镜像共置（将快照放在与基本镜像相同的存储中）
    • 这对于边缘情况可能很重要
    • (rosmaita) 我发誓我读过这个规范，但找不到它了

安全 RBAC 的第二次思考

为了为周五 TC 会议中 OpenStack 范围内的关于此问题的讨论做好准备，我们恢复了 Dan 和 Lance 在周二的“社区目标和“安全且一致的 RBAC”工作”会议期间提出的复杂问题讨论。想法收集在此 etherpad 上：https://etherpad.opendev.org/p/cinder-yoga-secure-rbac-more-thoughts

与 Nova 团队的跨项目会议

Nova PTG etherpad：https://etherpad.opendev.org/p/nova-yoga-ptg

卷重新镜像

Rajat Dhasmana (whoami-rajat) 有兴趣将当前的 nova 实例重新镜像功能扩展到卷支持的实例。（它当前仅支持从系统磁盘启动的实例。）有一些旧的蓝图


工作流程将是

  • 用户调用 nova -> 重新镜像服务器
  • nova 调用 cinder -> 重新镜像卷
  • cinder 告诉 nova -> 卷已准备好（nova 需要更新的连接信息）
  • nova 恢复
结论
  • Nova 团队支持此功能。它将填补当前服务器重新镜像功能中的空白。


一般讨论

星期五 10 月 22 日

录像

配额！！！

Gorka Eguileor (geguileo) 在 Xen 中做了一堆配额工作，但保留代码（从 nova 继承而来）比 cinder 真正需要的复杂得多。Gorka 希望在 Yoga 中就他想要改进 cinder 配额的方向达成一致。

Gorka 做了关于配额如何在 cinder 中使用以及为什么它们很复杂的快速演示。（观看录像！）

出现的一些问题是

  • 需要咨询真正的专家来正确设置索引并与当前性能进行比较。Simon 非常担心在 OpenStack API 中被认为是可接受的性能相对于后端性能来说非常慢，并且担心任何可能使 API 变慢的事情。但是，正如 Eric 每次提到这个问题时所指出的那样，数据库针对计数进行了优化，而计数比使用可能过时的存储值更好。Gorka 愿意与专家核实，以确保我们拥有正确的索引以使其快速。
  • 我们同意在滚动升级期间配额可以不一致地工作。似乎没有必要构建一个兼容层来保留升级期间“旧”配额系统（尤其是由于旧系统已经给你不一致的结果，没有人喜欢它！）

结论

  • 行动 (geguileo) 编写 Yoga 配额改进的规范

社区目标：安全的 RBAC

cinder 团队休会到 TC 会议的“Juno”房间。我们需要参与这次讨论，因为 system-* personas 的概念已经改变，我们需要更好地了解社区正在向何处发展。

正在进行的讨论在这个 etherpad 上：https://etherpad.opendev.org/p/policy-popup-yoga-ptg

此录制链接已排队到 RBAC 讨论：https://www.youtube.com/watch?v=RT492bi6Xto&t=2470s

我们还留下来参加了社区目标讨论；看起来 Yoga 只有一个目标。

结论

  • 我们希望在周期早期完成 Yoga 的工作，但现在有风险（因为我们不再确切知道这项工作是什么）。
  • 行动 (rosmaita, abishop)：参与 policy-popup 会议，尽快敲定此事

澄清卷驱动程序 API，第 2 部分

我们没有时间完成这个，但我们在第 1 部分中学到的是，这可能需要一些时间。一些函数和文档将很明显该怎么做，而其他函数可能需要进行一些研究。

结论

  • 我们将继续将其作为整个周期中的一项持续活动，也许作为“卷驱动程序 API 函数每周一例”，并逐步记录整个接口。

Yoga 优先级和责任

官方发布计划已更新为 cinder 特定的事件，因此你可以在那里查看日期和截止日期：https://releases.openstack.org/yoga/schedule.html

Cinder 项目的周期优先级

  • 安全的 RBAC
    • 我们官方的立场是，我们反对为了完成安全的 RBAC 而进行 hack
    • 我们将努力更好地定义需求，希望尽快
    • 如果正确的做法不清楚，可能会在列表调用中省略 all_tenants=true，然后在 Z 中修复它
  • os-brick
    • 在周期早期（在 Milestone 1 之前）关注那些不会破坏现有任何内容的补丁（因为它们是完全不同的路径）
      • gpg 加密
      • NVMe 代理
    • NVMe 多路径
  • cinder
    • Gorka 计划研究配额……将需要对 POC 补丁和规范进行高优先级审查，尽管我们可能无法在 Yoga 中完成实际工作
    • sqlalchemy-migrate -> alembic 补丁：希望在 Yoga 早期合并
    • 卷驱动程序 API 澄清……将在整个周期中对此进行工作（“每周一例函数”）并逐步澄清/改进卷驱动程序 API 定义
    • 重新镜像卷
      • 这还包括更好地处理我们联系 nova Events API 的方式
  • Rajat 的 cinder/glance 交互改进/优化
  • CI 情况
  • 静态类型检查
    • 我们相信，一旦我们有足够的覆盖率，这将包括代码质量，所以我们想继续这项工作
    • Eric 一直在发布和重新应用补丁，但没有得到太多的审查行动
    • 我们将整个周期都采用“mypy 补丁每周一例”来合并工作
    • 让 2 个核心 + 1 个非核心承诺审查补丁并快速重新审查，如果出现问题，以便在下周内合并它
  • 默认类型改进
    • （如周二讨论的那样）
    • 主要是文档更改
    • 可能会引入一个新的微版本来增强 volume-type-list 响应，以指示默认类型是什么

结论

  • 行动 (rosmaita) 更新驱动程序文档，其中包含有关 CI 联系 gerrit 时使用“autogenerated”标签的信息
  • 有些人赞成选择另一个“每周一例”补丁（非 mypy），但我希望等到我们看到 mypy 和 volume-driver-API-revision 工作进展如何
从"https://wiki.openstack.org/w/index.php?title=CinderYogaPTGSummary&oldid=179835"检索