跳转到： 导航, 搜索

CinderEpoxyPTGSummary

简介

Cinder 2025.1 (Epoxy) 周期第十次虚拟 PTG 于 2024 年 4 月 9 日星期二至 2024 年 4 月 12 日星期五举行，每天 4 小时 (UTC 1300-1700)。此页面将提供 PTG 期间讨论的所有主题的摘要。

本文档旨在提供每个会话的摘要。更多信息可在 cinder 2025.1 Epoxy PTG etherpad 上找到


会议已录制，因此要获取任何讨论的全部细节，您可以观看/收听录音。每个日期的录音链接都在各自日期的标题下方。

记录

总结

回顾

我们花了几分钟时间讨论了 Dalmatian 版本的状态，哪些方面做得好，哪些方面做得不够好，以及我们如何在 Epoxy 版本周期中改进。最值得注意的是，这个周期我们减少了两个核心。这给已经很大的评审队列增加了额外的压力。如果机会合适，我们将努力培养和提升任何合格的贡献者。

NetApp

我们讨论了 NetApp 在 Epoxy 周期中与功能开发计划相关的 6 个不同主题，以确保我们所有人保持一致。以下是完整的摘要

  • 基于证书的身份验证

目前仅实现了基本身份验证，这需要用户名和密码。强烈希望添加对基于证书的身份验证的支持。讨论涵盖了可能的方法以及一些有用的链接，指向可以作为参考的现有实现。

  • NVMe 驱动程序的 HA Active-Active 支持

这将允许用户在 cinder 集群环境中配置 NVMe 驱动程序后端。我们讨论了故障转移过程以及需要实现哪些方法。讨论了相关的用例以及测试场景。目前我们的上游 gate 中没有复制和故障转移覆盖，因此在开发阶段的测试和验证需要特别小心。提到 Rally 作为测试的可能性。

  • NVMe 的 SVM 范围支持

希望向 NVMe 驱动程序添加 SVM 范围的支持。目前驱动程序无法初始化。正在进行工作以添加对此功能的完全支持。没有提出令人担忧的问题，期待在 Epoxy 中实现此功能。

  • ASA r2 支持

ASA r2 系统使用存储单元和一致性组来简化存储管理和数据保护。REST API 不同，并且某些功能受到限制。让我们看看这个周期会如何发展，很好地关注着未来发展。

  • 复制 - Snapmirror Sync 支持

同步镜像通过在两个存储阵列上提供可用数据的副本来实现零数据丢失的恢复点目标 (RPO)，如果其中一个存储阵列发生灾难。由于每次对主卷进行写入时，都会对辅助卷进行写入，因此副本始终与生产数据相同。主机仅在成功更新辅助卷上的更改后才收到写入成功的确认。

  • Metrocluster 支持

Metro cluster 是一种具有同步复制的集群解决方案，可提供持续可用性，以事务方式立即复制所有关键数据。MetroCluster 配置增强了 NetApp 硬件和 ONTAP 存储软件内置的高可用性和非破坏性操作，为整个存储和主机环境提供额外的保护。讨论了一些超出驱动程序特定更新的更改，没有障碍。

处理 MYPY 更新

我们在 gate 作业中支持 mypy，但未固定版本会导致偶尔出现中断。我们固定 hacking 和类似工具，并且同意应将 mypy 包含在内。前提是我们记得定期取消固定并更新这些版本号以保持最新。

新的卷驱动 LVM+Clone

Jan Horstmann 提出了一种 LVM 驱动程序的衍生版本，以添加对使用设备映射器克隆目标以透明地迁移卷的支持。这将允许管理员利用本地存储来实现性能，同时仍然能够跨计算主机实时迁移实例。希望很快有一个 POC/Demo，没有发现根本性的障碍，非常期待看到它的实现。

备份服务的评审

很难获得与 cinder-backup 相关的更改的评审。Tobias 询问是否有任何核心可以花一些时间专门关注 cinder-backup（以及潜在的 backports）。我们同意在每周会议上提及备份评审队列和评审仪表板可能会提高认识。

新的 Location API 采用

Rajat 提出一个补丁，添加了对 `add_image_location` 方法的调用，该方法触发新的 location API 工作流，该工作流比旧的 location 工作流更安全、更强大。当 glance 使用 cinder 作为后端并且我们想要执行优化的“将卷上传到镜像”操作时，将进行此调用。还有一些补丁增加了对测试此功能的的支持。我们可能仍然需要 Glance 团队的一些输入，将在我们的每周会议中跟进。

向 AZ API 添加 `service` 查询参数

Tobias 提出一个 API 更改，向现有 API 添加一个查询参数。具体来说，向 os-availability-zone API 添加 `service` 查询参数。该补丁被认为已经完成并准备好进行评审。

添加备份摘要 API

Tobias 提出添加备份摘要 API（与卷可用的方式相同）。他还发现实施此功能时存在卷摘要 API 错误。该补丁已准备好进行评审。

Horizon 功能差距

我们很荣幸能够与 Horizon 团队会面并讨论他们为弥合现有功能差距所做的努力。讨论了几个具体内容并达成了清晰的认识。对 openstack 客户端和 SDK 之间可能存在不兼容问题表示担忧。此外，Horizon 仅在必要时更新 microversion，并且识别出审查 microversion 以查看是否可以利用任何附加功能是有价值的。

优化 RBD 从 Cinder 到 Glance 的更新

当前，当 cinder 和 glance 都使用 RBD 时，将 cinder 卷上传到 glance 镜像的路径并未优化。我们可以利用 RBD 分层（或写时复制克隆）来完成操作，无论卷大小如何，只需几秒钟（因为没有实际的复制发生）。

有 3 个已实施的功能是支持此功能所必需的

1. RBD 克隆依赖删除：我们已经在 glance 和 cinder 中登陆了更改，以处理 RBD 依赖链，因此从卷到镜像池的依赖关系不应该成为问题

2. 服务角色：目前附件删除 API 已经使用服务角色 + 服务令牌，我们可以对该功能使用类似的更改

3. 新的 location API：此新的 glance 功能消除了安全风险，因为即使在此优化路径中（在后台，因此我们的操作性能不会受到影响），我们也会计算镜像哈希。

  • 之前有几个障碍，现在似乎都已解决
  • 性能显著提升
  • Glance -> Cinder 已经支持
  • 回退到未优化的代码路径
  • 相关，最近对改进 RBD cinder/glance 的补丁，需要考虑/评审

Eric 承诺帮助评审。

卷复制的状态

花了一些时间讨论卷复制的当前状态。我们没有在 tempest 中进行测试覆盖，因此很难知道任何特定驱动程序实现的当前状态。有人提出向供应商征求用例和测试结果。该功能在各个项目中普遍缺乏清晰度，以及我们整体的灾难恢复解决方案是什么。

镜像加密 (Glance 跨项目)

这项工作的目标是在 Glance、Cinder 和 Nova 之间标准化加密镜像，以使其一致且易于用户访问。以下是回顾

1. 到目前为止，我们已合并了 os-brick 中的一个补丁集，该补丁集扩展了密钥处理，以支持更多类型的 Barbican 密钥进行镜像加密，除了 Cinder 现有的实现（该实现严格使用 binascii.hexlify() 转换）。

2. 已经编写了 Glance 的补丁集，以添加来自 Barbican 的 Secret Consumer API，用于加密镜像并处理新的标准化格式。

3. 已经编写了 Cinder 的补丁集，使其能够生成和使用新的标准化格式 + 此外，除了原始 LUKS 格式之外，还支持 qcow2+LUKS，以及来自 Barbican 的非十六进制密钥。

在与 Glance 的初步讨论之后，我们同意*不*引入任何新的 container_format 或 disk_format，而是使用 `os_encrypt_*` 属性来处理此问题（例如 os_encrypt_format=luks）；这是补丁集当前的实现方式。

但是，由于最近围绕镜像格式解析和转换的 CVE，人们担心这种方法可能会导致新的漏洞，因为 container_format、disk_format 和加密属性之间可能存在冲突和歧义。我们需要就一种新的方法来处理元数据中加密镜像的分类达成一致。我们至少需要考虑两种情况

1. 原始 LUKS（如 Cinder 当前从加密卷生成的）

2. qcow2+LUKS（如 Nova 为临时存储生成的）；用户也可以生成两者（请参阅参考部分中的 gist 链接）。

卷类型元数据进度

我们收到了有关卷类型元数据工作的进度更新。一致认为方向是正确的。除了对卷类型 show / create 的响应的更改之外，新的 API 端点需要一个新的 microversion。tempest 测试仍然需要进行调整。补丁需要评审。

OpenAPI 工作状态

初始补丁的吸引力很少，需要帮助获得第一个补丁集的评审。补丁还清理了技术债务并修复了几个错误，这将非常有用。

移除 uWSGI 脚本 (stephenfin)

删除 uWSGI 脚本的补丁已经发布，需要评审。相对较小的补丁。更新：此补丁已通过评审并合并。

Eventlet

创建了一个专门的 etherpad 来帮助记录当前状态。Cinder 仍处于调查阶段。我们不仅直接使用 eventlet，一些驱动程序（例如 RBD）使用生成本机线程的 C 库。我们必须小心处理这些情况。我们的目标是在 Epoxy 中只进行准备性更改（因为它是一个 SLURP 版本），并将重大更改保留到 F（大多数人不会升级到，因此这将给我们更多时间来检测和修复问题）

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