跳转到： 导航, 搜索

CinderAntelopePTGSummary

简介

Cinder 2023.1 Antelope 虚拟 PTG 于 2022 年 10 月 18 日（星期二）至 2022 年 10 月 21 日（星期五）举行，每天 4 小时（UTC 1300-1700）。此页面将提供 PTG 期间讨论的所有主题的摘要。

Cinder 2023.1 Antelope 虚拟 PTG 2022 年 10 月 19 日


本文档旨在提供每个会话的摘要。更多上下文可在 cinder Antelope PTG etherpad 中找到


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

星期二 10月18日

录像

用户调查反馈

https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030843.html https://docs.google.com/spreadsheets/d/1hHC4hg_Zt9FLYYJ7UA9iVomBbExUhhyJd2QpmrriiBQ/edit#gid=0

用户调查反馈评论总结如下 3 个部分

1) 完成


2) 可操作

  • 记录 HA 部署
  • 在不同的 Ceph RBD 后端（集群）之间进行在线重打字 ==> Eric 将尝试查看 libvirt 是否现在支持它
  • 加密改进：密钥轮换、多个 LUKS 密钥 ==> 可以探索一些想法


3) 问题

  • 真正的 Active/Active ==> 这具体是什么意思？
  • 使用 Pure iSCSI 进行实时迁移 ==> 这应该可以在新的 OpenStack 版本中工作
  • 错误管理
  • 更好的失败清理 ==> 例如，不将卷保留在已预留/分离状态？
  • 更好的创建/挂载/删除失败时的错误处理 ==> 用户消息？
  • 更好的对 cinder-backup 服务的支持 - 尤其是文件系统驱动程序。 ==> 驱动程序中的错误？
  • 卷组扩展 ==> 扩展卷？还是更多操作（哪些）？


用户调查问题回顾

操作员在用户调查反馈中提供的信息含糊不清，团队同意修改问题，以便在反馈中获得更有用的信息。

团队提出了一些好的想法，如下所示

  • 要求他们提供驱动程序以及协议
  • 修改列表以提及带有协议的驱动程序，以便操作员选择，例如 NetApp iSCSI、HPE3PAR FC 等
  • 按字母顺序排列会很好，并且易于找到相关的驱动程序-协议组合
  • 具体说明反馈，如果存在问题，请提供版本、launchpad 错误链接


基于这些要点，我们修改了用户调查反馈问题，如下所示。

https://etherpad.opendev.org/p/antelope-ptg-cinder-user-survey-current-questions

结论

  • 操作：Brian 将与 Allison 讨论修改后的调查反馈（PTG 后的状态：完成）

SLURP 发布节奏

引入 SLURP（Skip Level Upgrade Release Process）的概念，因为六个月的升级对于操作员来说是困难的、不可行的或不受欢迎的。2023.1 Antelope 将是 OpenStack 的第一个 SLURP 版本。以下是一些关于 SLURP 和非 SLURP 版本的细节。

  • 每隔一个版本将被视为“SLURP（Skip Level Upgrade Release Process）”版本
  • 除了相邻的主版本之间的升级外，还将支持“SLURP”版本之间的升级
  • 希望迁移到一年升级周期的部署将同步到“SLURP”版本，然后跳过下一个“非 SLURP”版本
  • 测试：测试 SLURP 版本之间的升级
  • 弃用：弃用、等待和删除只能在“SLURP”版本中进行
  • 数据迁移：支持“SLURP 到 SLURP”升级的一部分是保持从“SLURP 到 SLURP”稳定的（“兼容的”而不是“不变的”）数据库模式
  • 发布说明：https://review.opendev.org/c/openstack/project-team-guide/+/843457


详细信息：https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html

Cinder 已知的加密问题

演示：https://docs.google.com/presentation/d/1HOHnO9T3BD1KO5uk_y34aWhMs_A5i9ANPn6zIujQxCk/edit

这是一个复杂的问题，自多个 PTG 以来一直在讨论。讨论了另一个主题，“针对特定存储提供商（如 Dell PowerFlex）的分配大小与请求大小”，其中包含作为加密工作初始基础的工作项

  • 保留用于用户大小和实际大小的两个数据库字段
    • 请求大小 -> 用户大小
    • 分配大小 -> 实际大小
  • 分区卷，只有具有用户大小的分区才应在 VM 内部可见


加密工作将遵循此初始工作，以实现以下目标

  • 计算加密标头大小，以了解卷中可见的用户大小是多少
  • 在创建时开始加密卷，而不是在第一次挂载时进行加密

结论

操作：Sofia 在完成初始基础工作后将致力于加密工作

运维人员工时

Christian Rohmann 加入我们，向我们简要介绍了他们的部署以及他们对 cinder 的当前痛点。他们主要关注备份相关的事情，并讨论了许多备份主题。


1) 非 rbd cinder-backup 驱动程序的状态，例如 S3

当前的问题是，非 rbd 后端没有得到优化，因为它们逐块复制数据。此外，它们对不同类型的卷（如稀疏配置、加密等）效果不佳。

为了解决此问题，我们需要实现一个通用的块跟踪功能。我们可以将其分为两个部分：后端和前端。

  • 操作：Gorka 同意进行头脑风暴，以供将来参考


2) 备份层的加密

我们可以使用 barbican 或静态密钥在备份上实现加密层。密钥范围可以是全局的或基于项目的。


3) 我们当前拥有的备份功能

我们还讨论了操作员可以充分利用的我们当前拥有的备份功能

  • 限制并发备份/恢复操作
  • 垂直和水平扩展备份服务以提高性能
    • 我们可以配置备份的工作进程
    • 以 Active-Active 模式运行 cinder backup


4) 提到的一些其他问题以及操作员的痛点

  • 如果服务崩溃，则无法恢复备份过程，最好能够从中断的地方继续
  • RBD 镜像有一个锁，并且没有办法知道谁/什么留下了它
  • 对 RBD 感兴趣 512e/4k 支持
  • 在重新启动后恢复操作
  • 自动迁移池中的卷


从缓存创建卷时，缓存大小小于卷大小时的镜像缓存问题

镜像缓存是一个非常有用的功能，它允许我们从缓存克隆和扩展卷，而不是一次又一次地从 glance 下载整个镜像，从而提供优化。

我们面临的问题是，如果使用镜像缓存启用的第一个卷是一个大卷（例如 100GB），而从同一镜像创建的后续卷是小尺寸的（例如 10GB），那么后续卷也将被创建为与第一个卷相同的大小（即 100GB 而不是 10GB）。

我们讨论了可能的解决方法

  1. 使用请求的大小创建第一个条目，如果收到较小的请求，则更新缓存条目
  2. 使用镜像所需的最小尺寸的卷创建缓存条目
  3. 使用元组（image-id，size）查询缓存条目，并使多个缓存条目与单个镜像相关联


描述在 2. 中的解决方案似乎是最简单和最直接的实现方法。

结论

星期三 10月19日

录像

镜像加密工作更新

此功能的想法是提供对加密镜像的支持。这项工作目前取决于 barbican 侧的 secret consumer 工作。

https://review.opendev.org/q/topic:secret-consumers

os-brick 侧还有一个补丁可以查看：https://review.opendev.org/c/openstack/os-brick/+/709432

结论

操作：Cinder 团队审查 os-brick 的更改。

Cinder 不检查镜像数据完整性的场景

当 glance 中的 show_multiple_locations 配置选项设置为 True 时，我们允许恶意用户更新公共/共享镜像的位置信息。

此参数是 Cinder 使用 glance cinder store 进行某些优化所必需的。在这里，安全性是优化的权衡。我们也不在优化路径中执行镜像签名验证。

与此相关的 OSSN：https://wiki.openstack.org/wiki/OSSN/OSSN-0090

结论

启用卷池时，Cinder 的云特性不足

当部署具有后端报告的池时，卷池可能会因卷而填满。当有池已满时，所有位于已满池上的卷现在都可能在操作失败，而未满池中的卷不会失败。Cinder 应该缓解这种情况，并将正在操作的卷迁移到具有空间进行操作的池。操作员最终手动执行此操作作为修复失败操作的唯一解决方案。这种手动干预不可扩展，并且不是“云”。从客户的角度来看，他们卷上的操作应该可以正常工作。

在池已满的卷上失败的命令

  • backup
  • clone
  • snapshot
  • extend

由于还需要加上迁移卷所花费的时间，因此像克隆卷这样的操作将花费更多时间，如果选择的池已满，然后再克隆卷。

考虑将其配置为自动迁移或不迁移

  • 将其嵌入到卷类型中，以便可以迁移具有特定类型的卷
  • 将其保留在卷类型中，而不是全局配置选项
  • 两者可以一起完成

结论

  • 行动：Walt撰写扩展用例的规范（稍后可以更新，当其他操作也准备就绪时）

从 cinderclient 迁移到 OSC

当前 OSC 和 cinderclient 的差距：https://docs.openstack.org/python-openstackclient/latest/cli/decoder.html#cinder-cli

项目正在转向 openstackclient，例如 nova、neutron、keystone，glance 也正在计划。 cinderclient 和 openstackclient 之间的许多差距已经弥合。 愿景是将所有项目特定的客户端统一到 OpenStackClient，以提供更好的用户体验。

目前有两种方法可以进行 API 调用

  • 使用项目特定客户端中的 python 绑定
  • openstacksdk

openstacksdk 有 3 层

  • 资源层：设置和获取资源的属性
  • 代理层：充当连接到项目（nova、cinder）API 的服务器
  • 云层：将操作组合在一起

结论

  • 行动：Rajat（whoami-rajat）创建一个 OSC-cinderclient 的对等文档/表格 -- 检查 openstacksdk 以及 osc-cinderclient 的差距

cinder-backup 正在阻塞 nova 实例的实时迁移

由于卷状态锁（'backing-up'），如果正在进行卷备份，则无法实时迁移实例。

现有规范：https://review.opendev.org/c/openstack/cinder-specs/+/818551/

Gorka 认为，如果我们使用内部附件操作（例如在迁移期间的附件）的附件 API，我们可以从中受益

结论

星期四，10 月 20 日

录像

SRBAC 更新

根据与运营商最近关于范围的讨论，我们将仅限于项目范围，要实现的角色是项目管理员、项目成员和项目读取者。 Cinder 已经实现了所有角色，但策略中缺少 ``scope_type`` 限制。

Tempest 团队正在使用强制范围的策略进行测试，并将新的默认值设置为 True：https://review.opendev.org/c/openstack/tempest/+/614484

以下是 2023.1 的目标：（前 3 个很重要）

  • 默认情况下将 enforce scope 切换为 True
  • 默认情况下切换 enforce new defaults 为 True（也许，但肯定在 2023.2 之前）
  • 将 scope type 添加到策略 -- 针对 cinder
  • 实现服务角色 -- 首先需要在 keystone 中

结论

  • 更新策略矩阵
  • 删除之前已弃用的内容 -- 这与 SRBAC 无关，但我们将一个策略拆分为多个以支持粒度，现在删除旧的策略（例如：create_update 策略拆分为 create 和 update 策略）
  • 更新 policy/base.py 文件，以便 sample policy.yaml 中生成的字符串有意义
  • 可能还需要更改在基本文件中定义的并在所有单个策略文件中使用的“常量”的名称（因为这些也具有误导性）
  • 将 scope_type=['project'] 添加到所有规则
  • 关键点：旧版管理员（role:admin）应该能够在新的策略默认情况下执行他们能够在旧默认情况下执行的所有操作
  • 添加 tempest 测试：https://review.opendev.org/c/openstack/tempest/+/614484

用于 remotefs 驱动程序的辅助卷扩展

在文件系统类型驱动程序的情况下，它们目前不支持在线扩展。

正在讨论一种使在线扩展同步的方法：https://review.opendev.org/c/openstack/nova-specs/+/855490

人们担心网络故障，并且 cinder 可能会等待一段时间才能从 nova 收到回复，从而使操作变慢。 另一个担忧是，我们最终可能会有 2 条代码路径，一条带有扩展事件，另一条带有针对不同驱动程序的新的同步扩展。

结论

  • 行动：kgube 撰写规范，阐明需要在 cinder 端完成的设计更改，以支持 FS 驱动程序

Dell PowerFlex 等特定存储提供商的分配大小与请求大小

Dell Powerflex 驱动程序以不同的方式工作，它将每个卷容量四舍五入到 8GB 的倍数。 这种行为的问题是，当用户创建一个具有请求大小的卷时，DB 中显示的大小并不能反映后端正在创建的内容。

以下方法似乎可以解决该问题

  • 保留用于用户大小和实际大小的两个数据库字段
    • 请求大小 -> 用户大小
    • 分配大小 -> 实际大小
  • 分区卷，只有具有用户大小的分区才应在 VM 内部可见


只有管理员才能看到实际大小，这将需要在响应中报告新的微版本，并且还应在通知中发送实际大小。

结论

行动：JP 撰写规范，提及需要在以下方面进行更改的详细信息

  • os-brick 端（仅显示用户可见大小分区）
  • cinder DB 端（包括获取用户可见大小和实际大小的新微版本）
  • 优化：在 os-brick 端卷创建操作期间进行分区，而不是附加操作
  • 分区应始终存在（即使请求 8GB 卷），因为否则将无法扩展它
  • 使用允许递归分区的分区方法
  • 在扩展时，Cinder 需要扩展该分区
  • os-brick 需要在连接信息中接收一个新标志，以告诉它使用第一个分区并返回它（因为用户可以拥有带有分区的卷）

os-brick privsep 转换

Nova 已经从 rootwrap 迁移到 privsep 很多周期了，但 nova 需要保留 rootwrap 文件，因为 os-brick。 最近还报告了一个与此相关的安全问题：https://bugs.launchpad.net/os-brick/+bug/1989008

Stephen 提出了一些补丁，将 os-brick 代码从使用 rootwrap 迁移到 privsep。

结论

行动：审查 Stephen 提出的更改

可配置的软删除

https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030729.html

这个想法是使数据库记录的软删除可配置。 这将允许运营商，他们不想将 DB 记录存储为软删除条目，在资源删除时删除 DB 行。

这样做的好处是，无需以后每次都清除数据库，也不会遇到由于外键依赖和其他我们过去遇到过的问题而导致的清除失败问题。

Stephen 同意实现此功能。

结论

  • 行动：Stephen 提出一个补丁来实现此功能
  • 行动：Cinder 团队审查并添加有关任何疑虑的评论

星期五，10 月 21 日

录像

重置状态的健壮性

此功能改进了我们对各种资源的处理重置状态。

Tushar 添加了一个提醒，以审查他的补丁系列，因为它已经挂起 3 个版本了。

结论

只读附件

如果我们在从驱动程序返回的连接信息中传递 access_mode 参数，nova 端似乎可以处理此问题。

https://opendev.org/openstack/nova/src/commit/b1958b7cfa6b8aca5b76b3f133627bb733d29f00/nova/virt/libvirt/volume/volume.py

从 cinder 的角度来看，在导出/映射卷时限制访问模式仍然有价值。

结论

  • 行动：Rajat 询问 nova 团队他们是否目前正在使用 libvirt 进行只读附件（或者 libvirt 是否支持它）
    • Gorka 检查了 nova 代码，看起来是存在的
  • 行动：Rajat 继续研究 lvm + lio + iscsi 配置的单个附件情况

用户消息

用户消息仍然有意义，因为它们有助于检测异步操作中的故障。 消息框架进行了一些修改，使用上下文来传递值，从而使创建消息调用具有更少的参数。

此外，Brian 提到我们传递的消息和异常之间存在互斥条件。 异常具有通用映射，允许将其映射到通用消息，因此我们应该只传递消息或异常。

如果得到适当的指导，这将是实习生的一个好任务。

结论

  • 行动：在贡献者文档中提及添加用户消息的新方法（通过传递上下文）

与 glance 的跨项目

1) 继续讨论安全问题 https://wiki.openstack.org/wiki/OSSN/OSSN-0090

Zed 周期中提出了一种规范，试图处理相同的问题。

新的位置 API 规范：https://specs.openstack.org/openstack/glance-specs/specs/zed/approved/glance/new-location-info-apis.html

讨论的结论是以下方式修改现有规范

位置 ADD API

  • Erno 提到我们只想在创建镜像时，当镜像处于 QUEUED 状态时添加位置一次，并且不应允许在镜像处于活动状态后添加位置
  • 这不需要服务角色，并且 glance 端的基本检查镜像状态就足够了


位置 GET API

  • 这仍然需要服务角色，因为我们不想向最终用户公开位置


HTTP 存储问题

  • 我们希望在添加位置时有一个标志，表明“我们希望对该镜像进行校验和检查”
  • 通过允许在其中传递元数据，可以使用新的位置创建 API 来实现这一点

结论

  • 行动：Rajat 更新规范，其中包含最新的讨论
  • 行动：Brian 与 Keystone 团队进行交互，以获取服务角色


2) 重构 cinder 驱动程序

重构 glance cinder 存储，使其更具可读性。

结论

讨论在 FS 驱动程序中处理卷格式的方法

当我们创建附加卷的快照时，活动文件会更改为快照，并且 cinder 端应将格式更新为 qcow2 以及活动文件（我们应该当前正在执行此操作）。

我们还需要修改当前块重基和块提交的快照删除用例，以处理建议的补丁中进行的更改。

一个 tempest 测试将很好地测试此场景。

结论

在 API 中报告池容量因子

我们提出了一项更改，将在 API 响应中按池报告功能因子。 似乎是一个好主意，可以在 get-pools 命令中完成。

结论

标记池为关闭的机制

总体思路是将状态与池相关联（例如，当池已满时，池关闭），以便调度程序可以根据该池的状态做出决策。 例如：当池 100% 满时，我们将其标记为关闭，并且我们将添加一个 PoolDownFilter 到调度程序，以确保调度程序不允许对已关闭的池进行配置。

Walt 在他的 repo 中完成了这项工作


这将允许将池设置为多种状态：UP、DOWN、DISABLE、DRAINING、MAINTENANCE 等

结论

  • 行动：Walt 撰写规范，提及以下情况
    • 添加一个过滤器以检查池状态
    • 在多个管理器的情况下，添加一个领导者选举算法来确定哪个管理器应该报告统计信息
    • 一个用于运营商设置池状态的新 API

备份恢复到稀疏卷

我们面临的问题是将备份恢复到瘦卷不是稀疏的。

当前实现的方法是查找零块并跳过它们：https://review.opendev.org/c/openstack/cinder/+/852654

该方法对于新卷很好，但会对现有卷造成问题，我们应该将零写入它们。

结论

  • 行动：Pete 找出恢复到现有卷与新卷的情况（对于新卷，我们可以像现在这样操作）
  • 行动：Pete 比较 sha256 解决方案与自动检测零

强制从数据库删除卷

这已经在 Zed PTG 中讨论过。用例是在后端不存在卷时，能够从 cinder 删除卷。

讨论的解决方案是在 unmanage 操作中添加参数来处理删除数据库记录的情况。

有一个提议是将此添加到 cinder-manage 命令行，但似乎不是正确的方法

结论

  • 行动：Eric 同意撰写规范，详细说明讨论的解决方案
从 "https://wiki.openstack.org/w/index.php?title=CinderAntelopePTGSummary&oldid=182933" 检索