跳转到： 导航, 搜索

CinderVictoriaMidCycleSummary

简介

在 Victoria (虚拟) PTG 上，我们决定举行两次中期会议，每次两个小时。第一次会议将在 Cinder 规范冻结之前进行，第二次会议将在新功能状态检查点附近进行。因此，中期会议将在 R-16 周和 R-9 周进行（以免与 Kubecon 冲突，Kubecon 在 R-8 周举行）。

第一次会议：R-16：2020年6月24日

我们通过 BlueJeans 从 UTC 14:00 到 16:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-victoria-mid-cycles
录像: https://www.youtube.com/watch?v=WS8ylhbjT2s

Cinder 项目更新

针对 stein (2.8.6) 和 train (2.10.4) 的新 os-brick 版本已经发布，以解决 Bug #1883654（修复 OSSN-0086 在 Python 2.7 上不起作用的问题）。包含新 os-brick 库的 cinder 版本在 gate 上出现了一些问题；train (15.3.0) 应该今天发布，stein (14.2.0) 很快也会发布。

您可以通过查看 Launchpad 来跟踪已发布的内容


我正在寻找一位 Cinder 的“发布负责人”志愿者。您不必是核心贡献者，您只需要是 Cinder 社区中负责任且活跃的成员。如果您有兴趣了解更多信息，请通过电子邮件或 IRC 与我联系。

我们同意尝试每月举行一次视频会议的实验；它将在每周例会时间（每个月的最后一个星期三）进行（我们将根据需要进行调整，以解决冲突）。所以第一次会议将在 7 月 29 日举行。我们将对要使用的视频会议软件进行投票。

操作

  • rosmaita - 发送关于每月视频会议的调查

备份

Ivan 要求对他的“备份后端配置”规范提供一些反馈，https://review.opendev.org/#/c/712301/

他的问题是关于数据模型，他是否应该重用现有表来处理 volume_types，因为他需要 backup_types 的内容非常相似，或者他是否应该添加新表。经过一些讨论，团队一致认为新表更安全，并且在 volume_types 和 backup_types 随着开发而变化时，更灵活。

操作

移除 Brocade FCZM 驱动？

Brocade 光纤通道区域管理器驱动程序在 Ussuri 中被声明为“不受支持”，并将在 Victoria 中通过 https://review.opendev.org/#/c/696857/ 移除。

供应商宣布在 Train 之后不再提供支持，并且不打算支持 python 3：https://docs.broadcom.com/doc/12397527（警告：打开 PDF）。因此，我们在 Ussuri 和 Victoria 中处于一种奇怪的境地，因为供应商明确否认了 python 3 的支持，而我们只支持 python 3。但我们不想只剩下 1 个 FCZM，所以我们之前同意将驱动程序保留在树中，但标记为“不受支持”，只要我们认为它可以在 Python 3 下运行。

现在我们有证据表明 initialize-connection 在 python 3.6 下会失败（代码期望一个列表，但得到一个迭代器）。我们目前不知道这个问题在代码中有多普遍，而且我们也没有第三方 CI 来验证更改。但对于 Cinder 来说，只有一个 FCZM 驱动程序看起来不太好。此外，我们不知道移除它会影响多少人。

经过一些讨论，我们决定执行以下操作

1. rosmaita 将发布一个删除 Brocade FCZM 驱动程序的补丁，但我们将将其标记为 WIP。

2. Gorka 将尝试抽出时间来研究它，看看他是否可以修复它。如果他不能，我们将继续删除它。

3. 同时，rosmaita 将向 ML 发送一封说明情况和存在删除补丁及日期的邮件；希望受到影响的人会站出来告诉我们。

4. 我们将在中期会议的第二部分（大约 7 周后）回顾这种情况。

操作

卷列表查询优化

haixin 正在推动这项工作。他有一个规范和一个补丁


大致来说，问题是如果用户尝试按 status=error 过滤卷详细列表，则一些处于错误状态的卷（特别是那些在“管理”过程中发生错误时处于错误状态的卷）不会出现在列表中。该建议是让所有处于错误状态的卷都显示出来

看起来这可能需要 API 更改，因此我们讨论了一个新的微版本，并可能添加某种标志来显示所有错误。您可以在 etherpad 上阅读一些有趣的观点，https://etherpad.opendev.org/p/cinder-victoria-mid-cycles

我有一个总结讨论内容并在规范评审上发表评论的任务，因此您可以去那里查看摘要：https://review.opendev.org/#/c/726070/

操作

  • rosmaita - 总结规范上的讨论（完成！）
  • haixin - 需要在规范、etherpad、ML 或 IRC 上解释他计划如何实现更改（看起来这里有 3 个不同的错误）
  • 有兴趣的人 - 确保当卷进入这些“管理”状态时，会创建用户消息，以便向用户提供更多关于发生情况的信息

支持还原到任意快照

xuanyd 提出了这个主题，他有一个提出的规范：https://review.opendev.org/#/c/736111/

目前，Cinder 仅支持还原到最新快照。许多（很多？）存储供应商支持还原到任意快照。Cinder 也应该这样做。

大部分讨论是关于 Cinder 项目的策略，如果一个特性可以以通用的方式实现，那么就应该这样做，并且支持优化的版本的后端可以覆盖通用实现以使用原生支持。由于有一种通用的（虽然效率较低的）方法来支持还原到任意快照，因此暴露此特性必须包括提供通用实现，然后支持它的后端可以宣传使用原生支持。关键点是社区反对将此添加到 API 中，通用实现会引发“未实现”异常。

然后讨论转向通用实现应该如何进行。一个关键问题是，您还原卷到的快照之后会发生什么。这需要在规范中解决，也许以 RBD 作为参考架构。

问题是有多少驱动程序已经原生支持此功能。 Inspur MCS 驱动程序、RBD 驱动程序和 IBM Storwize 驱动程序已经过测试；看起来 Dell EMC SC Series 驱动程序也应该能够做到这一点。

讨论已经在规范评审上引发了热烈的讨论，因此请参阅 https://review.opendev.org/#/c/736111/ 以获取更多详细信息。

操作

  • 所有感兴趣的评审员 - 在规范上留下评论

Victoria Milestone-1 评审

这是一个短周期，M-1 上周已经发生。目前的情况是我们没有达到 M-1 的任何目标。因此，未来两周的首要任务是与 Victoria Milestone-1 蓝图 相关的补丁，特别是

操作

  • 大家 - 审查以上内容！

第二次会议：R-9：2020年8月12日

我们通过 BlueJeans 从 UTC 14:00 到 16:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-victoria-mid-cycles
录像

Cinder 项目更新

下一次 PTG 计划于 2020 年 10 月 26 日至 30 日举行，即峰会之后的一周。参加不收取费用，但基金会希望您注册：http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016424.html

我们在 Victoria 周期中的位置：https://releases.openstack.org/victoria/schedule.html

  • 这是 R-9 周（ussuri 周期尾随发布截止日期；ussuri cinderlib 已发布；请参阅 https://launchpad.net/cinderlib/+series）
  • 距离 Cinder 新功能状态检查点和驱动程序功能声明还有 1 周
  • 距离最终非客户端库发布还有 3 周（R-6）（os-brick）
  • 距离 Ussuri 的最终客户端库发布还有 4 周（R-5）
  • 距离 Milestone-3 和功能冻结还有 4 周（R-5）
  • 距离第三方 CI 合规性检查点还有 4 周（R-5）
  • 距离 Victoria 社区目标完成还有 4 周（R-5）
  • 距离 RC-1 目标周还有 6 周（R-3）

操作

gate 问题

我们目前正在遇到 cinder-tempest-plugin-lvm-lio-barbican 和 cinder-grenade-mn-sub-volbak 作业的问题。

cinder-tempest-plugin-lvm-lio-barbican 失败与 os-brick 中添加的一个新的 bindep 相关，但 cinder 或 cinderlib 并非直接依赖它。我们尝试了各种修复方法，结果好坏参半。Luigi 最终找到了 devstack 认可的解决方法：https://review.opendev.org/#/c/745838/ 看起来这已经修复了 zuul 作业，一旦 QA 团队批准，我们应该就能恢复正常。

Melanie Witt 发现 cinder-grenade-mn-sub-volbak 失败是由 msgpack 的更新引起的，导致 Keystone token 处理出现问题：http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016446.html 一旦她的补丁合并，cinder-grenade-mn-sub-volbak 希望就能通过我们的测试。

操作

Ceph iSCSI 驱动

简而言之，我们将在 Wallaby 早期进行审查和合并。

有很多活动部件，包括驱动程序、CI 作业、brick 更改和 ceph 项目。Walt 报告说事情基本都在收尾阶段。

该驱动程序依赖于 rbd-iscsi-client。一些当前的 Cinder 驱动程序也有客户端，其代码与驱动程序代码一起位于 cinder 树中。Walt 倾向于保持分离，因为 rbd-target-api 可能会更改，并且这使我们可以随意更新 rbd-iscsi-client 内部结构，以跟上 rbd-target-api 的更改，并且 ceph-iscsi 驱动程序将继续工作。共识是这样做有意义，我们应该保持 rbd-iscsi-client 分离。我们将使用“独立”发布模型将其作为 cinder 项目引入，这很有意义，因为其更改与 Ceph 项目相关，而不是 OpenStack。

操作

  • cinder 团队 - 审查上述内容
  • rosmaita - 开始准备将 rbd-iscsi-client 作为 cinder 项目交付物的文件工作

审查 Brocade FCZM 驱动程序的情况

Brocade FCZM 驱动程序在 Python 3 中无法工作。（Brocade 决定不再支持 Python 2.7）。Gorka 主动获得了 Brocade FC 交换机，以便测试 FCZM 驱动程序，并且他已经提出了补丁来修复它以在 Python 3 中运行：https://review.opendev.org/#/q/project:openstack/cinder+branch:master+topic:brocade

该驱动程序在 Ussuri 中被标记为“不受支持”，并且在 Victoria 中可能会被删除。我们希望将 Gorka 的补丁回溯到 Ussuri（仅支持 Python-3）和 Train（因为这是很多人正在过渡到在 Python 3 中运行的地方，即使 2.7 仍然受支持）。

我们讨论了在 Victoria 中如何处理该驱动程序。大约一年前，我们调整了“不受支持”驱动程序删除策略，以便我们不会在最早的机会立即删除不受支持的驱动程序，以便为驱动程序维护者提供更多时间来使其第三方 CI 正常工作（这是最大的问题）。Brocade 的情况有点不同，因为供应商宣布对 FCZM 驱动程序在 Train 之后不感兴趣。

Gorka 建议他可以使用 Victoria RC-1 运行 CI 测试来验证驱动程序。我们可以在文档和发行说明中明确说明情况。从历史上看，它一直是一个稳定的驱动程序（除了 Python 3 的问题），因此至少是合理的。我们可以在 Wallaby 中期重新审视这种情况。

作为补充说明，团队在六月底宣布了该驱动程序的即将删除：http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015692.html 我们希望获得用户对维护此驱动程序的意愿的反馈，但没有收到任何回复。

操作

  • rosmaita - 提交关于文档和发行说明的补丁，如上所述
  • geguileo - 为 Brocade FCZM 运行 CI，使用 cinder RC-1
  • rosmaita - 回复邮件列表帖子，宣布我们的决定

支持卷重新镜像

我们对 rambo-li 提出的实施卷重新镜像功能的建议进行了快速讨论，该功能已在 Stein 中获得批准，重新定位到 Train，但从未实施。

  • cinder 规范需要重新提交到 Wallaby
    • 包括使用 Nova 外部事件 API 来通知操作结果的建议
    • 需要包括 cinder-tempest-plugin 测试，以确保一切正常工作
    • 修改将尝试重新镜像的卷状态

Eric 提到代码可能需要对 NFS 进行显式测试，不能假定它会像其他驱动程序一样工作

操作

  • rosmaita - 将 ^^ 放到当前补丁中
  • rambo-li - 修改规范

重新审视备份恢复中指定可用区或卷类型的需求

Alan Bishop 提出了一项未实施的 newton 规范，该规范允许为备份恢复 API 指定可用区和/或卷类型，主要是为了让他知道他对从事这项工作感兴趣，并确保社区仍然认为这是一个好主意。他指出最近的 Launchpad 错误表明用户对这个主题感兴趣。共识是这仍然是一个值得实施的功能，而 Alan 恰好是为此人选！

操作

  • rosmaita - 移除规范中的当前 assignee，并将其重新定位到 Wallaby

正在进行的镜像加密工作更新

Luzi 向我们介绍了关于正在进行的镜像加密工作的情况。Barbican Secret Consumer API，这是该方案的关键部分，已经基本完成。考虑到 Victoria os-brick 发布只有 3 周的时间，我们同意这看起来像一个 Wallaby 功能了。

正在进行的 os-brick 补丁是 https://review.opendev.org/#/c/709432

操作

  • rosmaita - 重新定位 Wallaby 的规范

加密卷的大小调整（继续）

问题（大致）：加密卷必须有一个标头，这会占用一些空间；当您从非加密卷类型重新调整“完整”卷到加密卷类型时，没有足够的空间用于标头，因此重新调整失败。

Sofia 报告了她在 cinder 每周会议上制定的一种方案的努力，即允许在重新调整时指定新的大小（或“允许扩展”标志或类似的东西）。问题是驱动程序以不同的方式优化迁移，并且由于我们之前没有新的大小参数，因此没有简单的方法将此信息传递给驱动程序。共识是 Sofia 将编写一个规范来更改驱动程序 API 以启用迁移大小调整，并建议如何/是否处理卷的显示大小与卷的实际大小。她还将准备一份 etherpad，概述这将是什么样子。

操作

  • enriquetaso - 编写上述规范和 etherpad

NFS 在线扩展

Lucio 准备了一个专门的 etherpad，其中包含讨论要点，因此请参阅该 etherpad 以获取完整详细信息：https://etherpad.opendev.org/p/fix-nfs-online-extend

计划是让 Nova 执行在线扩展。工作流程大致是 Cinder 被告知扩展到大小 N，Cinder 在 DB 中更新卷的大小，要求 Nova 执行异步操作。Cinder 轮询 nova server-action API 以监视操作的状态。如果扩展失败，Cinder 需要将原始大小恢复到 DB 中。如果 cinder 服务在轮询时关闭，则卷可能会保持不正确的状态。

Gorka 建议我们可以这样做

  • 将实际当前大小存储在卷的 admin 元数据中
  • 将卷状态保留为扩展中
  • 如果 Nova 成功完成操作，则将卷状态更改为使用中
  • 如果 nova 失败，则恢复
  • 在服务启动时添加清理程序，以检查 Nova 的操作中处于扩展状态的卷，这些卷具有 admin 元数据内容，并且如果已成功完成，则将状态更改为使用中，如果失败，则恢复它

之前有人抵制让此操作依赖于轮询外部 API，但共识似乎是对于这种情况，这是我们能做的最好的。

Sofia 正在使用 cinder-tempest-plugin 测试来测试常规和加密卷的在线扩展，因此我们将能够使用 NFS 后端来验证它是否有效。Lee Yarwood 目前正在处理与加密 NFS 卷相关的错误：https://bugs.launchpad.net/cinder/+bug/1888680

之前有人提出了在创建快照时确保在线扩展不会同时进行的问题；Lucio 提交了一个补丁来在创建快照期间锁定卷。

一个悬而未决的问题是，是否可以在启用 multiattach 时安全地执行此操作；Lucio 将研究一下。

最后一点是，Windows SMB 驱动程序显然可以执行此处概述的内容（即，扩展发生在 Nova 端）。值得研究他们是如何做到的。

操作

  • lseki - ping lyarwood，查看 LP Bug #1888680 的状态
  • lseki - PoC 如果 Nova 可以扩展 multiattached NetApp NFS 卷
  • lseki - 研究 Windows SMB 驱动程序（也许与 Cloudbase 的 Lucian Petruț 交谈）

os-brick 过滤器

Rajat 提出了一个关于 os-brick rootwrap 过滤器的问题，这些过滤器在 os-brick 代码库的 etc/os-brick/rootwrap.d/os-brick.filters 文件中定义，即我们是否需要它们，因为 nova 和 cinder 和 glance_store 在自己的文件中定义了这些过滤器？

事实证明 os-brick 文件未实际使用的原因是，更广泛的 openstack 社区有一种感觉，库不应该运送配置文件。有一个未批准的 devstack 补丁来自 2015 年，您可以在其中跟踪讨论：https://review.openstack.org/#/c/207677/

因此，归根结底的是，使用 os-brick 的人需要是 root（如使用 python-brick-cinderclient-ext 建议的那样），在这种情况下不需要过滤器，或者必须自己配置过滤器（在这种情况下，他们将如何知道需要哪些过滤器）？共识是现在应该保留这些文件，作为库使用者需要添加到其 rootwrap 配置中的过滤器的文档。

操作

  • 每个人 - 如果有一个更彻底的解决方案，那就太好了；也许有人可以想到一些东西

备份驱动程序

我们时间不够了，所以这将推迟到每周 Cinder 会议。

  1. 我们是否应该要求备份驱动程序的第三方 CI（我们目前没有）？
  2. 最近 Ivan 发现 IBM TSM 备份驱动程序损坏了，该怎么办？（我已向 IBM 的某人发送电子邮件，试图获取一些信息。）

操作

  • rosmaita - 跟进上述内容
从 "https://wiki.openstack.org/w/index.php?title=CinderVictoriaMidCycleSummary&oldid=175910" 检索