跳转到： 导航, 搜索

CinderUssuriMidCycleSummary

简介

由于 Ussuri 中期会议将以虚拟方式举行，我们不必担心物理安排，并决定将其分为两个独立的两小时会议。第一次会议将在 1 月最后一周的 Cinder 规范冻结期间举行，第二次会议将在 3 月 16 日左右的“Cinder 新功能状态检查点”期间举行，距离客户端库的最终发布还有 3 周。

第一次会议：2020年1月21日

我们通过 BlueJeans 从 UTC 13:00 到 15:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning
录像: https://www.youtube.com/watch?v=Dz28U1pQnqA

“停止对Py2的支持”社区目标

我们一直在 etherpad 上跟踪此目标：https://etherpad.openstack.org/p/cinder-ussuri-community-goal-drop-py27-support

目前，所有 Cinder 项目交付成果不再检查/门控 Python 2。官方 Ussuri Python 运行时是 3.6 和 3.7，并且 tox 已配置为同时为 3.6 和 3.7 提供单元和功能测试环境，并且每个项目的 .zuul.yaml 中的检查/门控配置已配置为同时运行 3.6 和 3.7。

所有组件都将进行主要版本升级，以表明不再支持 Python 2.7。

稳定分支上的 upper-constraints 文件阻止仅支持 py3 的库与稳定版本一起使用。手动修补系统的部署者需要注意 upper-constraints，以免无意中引入未经 Python 2 测试的最新库版本。

操作

  • rosmaita - 在更改 tox.ini 和 .zuul.yaml 时，发现对于我们以前的 py3 测试中的某些内容，实际测试的版本取决于系统 python3。后来的“drop-py2-support”补丁设置为针对单元和功能测试测试 py3.6 和 py3.7，需要验证这是否适用于所有 Cinder 交付成果。

Volume Local Cache 规范

Liang 已经更新了规范。我们试图在 Cinder 和 os-brick 方面保持简单，因为缓存的配置，包括使用的缓存模式，完全独立于 Cinder（并且可以动态更改）。当前建议是使用“可缓存”卷类型，用户可以通过选择合适的 flavor（或 nova 决定可以接受的任何其他方式）来控制是否实际缓存。对于某些缓存模式，您无法进行实时迁移或重新调整卷类型，因此看起来某种关于缓存模式的信息必须进入 cinder，以便可以阻止不适当的操作。也许对于第一个实现，os-brick 只能在连接时允许安全的缓存模式，并且我们可以记录操作员应该只使用安全的模式，并且不应动态更改缓存模式。

操作

  • Liang 将更新规范。尚不清楚缓存模式信息将如何传播到 Cinder；我们将在每周会议上讨论。

使用 six

我们在 PTG 上就使用仅 Python 3 语言功能达成了一些指导原则，但事实证明它们有点模糊，尤其是在如何处理在驱动程序中使用 six 兼容性库的新代码方面。例如，有这个补丁：https://review.opendev.org/#/c/701542/

这些是 PTG 指南

  • 提醒审阅者：我们需要非常仔细地检查测试用例的代码覆盖率，以便新代码具有出色的覆盖率，并在稳定分支中进行回溯时，如果使用 py2 进行测试，则很可能会失败
  • 提醒提交者：在审阅者要求更多测试时，请耐心等待！
  • 提醒社区：新功能可以使用 py3 语言结构；可能需要回溯的 bugfix 应该更保守，并为 py2 兼容性编写
  • 提醒驱动程序维护者：^^
  • Ivan 和 Sean 获得绿灯，可以开始删除 py2 兼容性

经过一些讨论，我们决定

  • 我们将允许驱动程序自行决定继续使用 six
  • 我们不会从影响驱动程序的代码中删除 six（例如，它们继承的类）
  • 我们可以从不影响驱动程序的代码中删除 six，请记住，回溯可能会更具问题，因此确保我们拥有真正好的测试覆盖率

操作

  • rosmaita - 将其写成对贡献者文档的更改，我们可以都在审阅中争论

第三方 CI 的当前状态

Jay 一直致力于删除在 Train 中标记为“不受支持”并在 Ussuri 中需要删除的驱动程序，以及标记 CI 未维护的驱动程序在 Ussuri 中为“不受支持”。这变成了一个令人沮丧的大量驱动程序。

我们讨论了围绕这个主题的一些问题。

我们需要对不受支持的驱动程序进行升级检查吗？

不，我们决定当前的日志通知和发布说明以及您需要在配置中启用不受支持的驱动程序的事实，为操作员提供了足够的关于驱动程序即将删除的通知。

我们现在应该停止删除驱动程序吗？

是的，至少再过几周。Eric 建议我们重新考虑删除策略，而 Walt 指出问题中的一些驱动程序被广泛使用（看看 HPE），对于想要使用它们的运营商来说，这将是一个麻烦。因此，延长“不受支持”期可能是有意义的。另一方面，Sean 指出，我们可能会在保持树中的非维护驱动程序方面遇到问题，尤其是当主库更新到仅在 python 3.6 和 3.7 上测试过的版本时。

那些已经删除的驱动程序怎么办？

如果供应商完全不感兴趣，过去几周删除的驱动程序可以恢复。例如，Brocade 发表声明，他们将不再支持其 OpenStack 驱动程序超过 Train 版本（他们只想支持 Python 2）。这是一个简单的决定。除了评估供应商的“兴趣”，Sean 指出这会引发公平问题，即，那些在上一轮（或前一轮）中删除的驱动程序怎么办。我们需要进一步讨论这个问题，以便制定一致的策略。

我们能让运行第三方 CI 更容易吗？

Luigi 报告了“Software Factory”工作：https://www.softwarefactory-project.io/

Software Factory 基本上是对 CI 系统的打包，因此无需从不同的部分组装和构建它。RDO 使用它来执行其 CI。有一个文档补丁用于 Software Factory，可以进行一些审阅/反馈：https://softwarefactory-project.io/r/#/c/17097/

那里已经有一些文档解释了如何将 CI 钩接到 openstack gerrit：https://www.softwarefactory-project.io/docs/3.4/operator/quickstart.html#third-party-ci-quickstart

我们的希望是这将使设置和维护第三方 CI 更加容易。此外，如果很多人使用 Software Factory，维护者将更容易获得帮助。

我们应该重新考虑第三方 CI 的要求吗？

当前要求是第三方 CI 必须在所有更改上运行，无论它们是否影响该驱动程序。我们最终在大多数补丁中得到一个很大的失败列表，您会滚动浏览它以获取审阅中评论的列表，并且只有在审阅驱动程序更改时才会注意它们，然后才查看该供应商的 CI 结果。

Sean 指出这不是一个新的讨论。以下是一些关于 2017 年的想法：https://wiki.openstack.org/wiki/CinderPikePTGSummary#3rd_Party_CI_Requirements http://eavesdrop.openstack.org/meetings/cinder/2017/cinder.2017-03-15-16.00.log.html#l-267

出现的一些其他问题是：如果这是一个资源问题，也许只需要每天运行一次 CI？归根结底，我们这里有一个很大的约束满足问题。

操作

  • 每个人 - 查看 Software Factory 补丁 https://softwarefactory-project.io/r/#/c/17097/
  • jungleboyj - 将尝试联系 CI 有问题的供应商，并在 1 月 29 日的会议上报告
  • rosmaita - 准备一些内容来组织这次讨论（我们的文档补丁或 etherpad），以便在 1 月 29 日的会议上进行

第二次会议：2020年3月16日

我们通过 BlueJeans 从 UTC 12:00 到 14:00 举行会议。
etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning
录像: https://www.youtube.com/watch?v=cA_VfYnS77o

欢迎和一些 Cinder 项目事务

我们当前周期的提醒

  • 这是 R-8 周（Cinder 新功能状态检查点）
  • 距离最终非客户端库发布还有 2 周，在 R-6
  • 距离 Ussuri 的最终客户端库发布还有 3 周，在 R-5
  • 距离 M-3 和功能冻结还有 3 周（R-5）
  • 距离第三方 CI 合规性检查点还有 3 周（R-5）
  • 距离 RC-1 目标周还有 5 周（R-3）


来自 stable/train 和 stable/stein 的发布将在本周提出。最终 rocky 版本发布于本月早些时候。

PTL 自荐将于下周开始。有兴趣的人可以与 Jay、Sean 或 Brian 谈谈，以了解这项工作的内容。


cinder 核心团队：有兴趣在 Cinder 项目中承担更多责任的人应该联系任何当前核心成员，以获取关于如何实现这一目标的指导

操作

rosmaita 本周提出 stein 和 train 的发布

resource_filters 响应

这是对本周期初每周会议的后续讨论：http://eavesdrop.openstack.org/meetings/cinder/2020/cinder.2020-02-05-14.00.log.html#l-177

简而言之，该 API 调用旨在帮助 API 实现自文档化，通过为用户提供一种以编程方式确定在请求各种 Cinder 资源列表时可用的筛选器的途径。当前的默认响应（可由操作员配置）如下

{
    "volume": ["name", "status", "metadata",
               "bootable", "migration_status", "availability_zone",
               "group_id", "size", "created_at", "updated_at"],
    "backup": ["name", "status", "volume_id"],
    "snapshot": ["name", "status", "volume_id", "metadata",
                 "availability_zone"],
    "group": ["name"],
    "group_snapshot": ["name", "status", "group_id"],
    "attachment": ["volume_id", "status", "instance_id", "attach_status"],
    "message": ["resource_uuid", "resource_type", "event_id",
                "request_id", "message_level"],
    "pool": ["name", "volume_type"],
    "volume_type": ["is_public"]
}

每个元素都是一个资源名称，其中包含可以应用于它的筛选器列表。

但是，URL 中的资源名称与这些不匹配

GET /v3/{project_id}/volumes
GET /v3/{project_id}/volumes/detail
GET /v3/{project_id}/backups
GET /v3/{project_id}/backups/detail
GET /v3/{project_id}/snapshots
GET /v3/{project_id}/snapshots/detail
GET /v3/{project_id}/groups
GET /v3/{project_id}/groups/detail
GET /v3/{project_id}/group_snapshots
GET /v3/{project_id}/group_snapshots/detail
GET /v3/{project_id}/attachments
GET /v3/{project_id}/attachments/detail
GET /v3/{project_id}/messages
GET /v3/{project_id}/scheduler-stats/get_pools
GET /v3/{project_id}/types

讨论中的一些要点

  • 理想情况下，你希望从你正在查询的 $resource（例如，'volumes'）开始，然后在 JSON 响应中查找适用的过滤器列表。但是，如果人们已经适应了当前的情况，那么“修复”它会破坏他们的使用。
  • 也许可以做一个调查，看看操作员们是如何使用这个功能的
  • 关键问题是，当我们添加新的资源时（例如，https://review.opendev.org/#/c/708845/），我们需要保持一致性
  • 与 URL 资源名称的一致性应该使其自我记录；我们可以放弃这一点，并加强文档

操作

  • rosmaita 整理了一份操作员调查，以了解使用情况

Bug #1852106 的后续影响

https://bugs.launchpad.net/nova/+bug/1852106

这个问题目前已经修复（你将无法通过 nova 创建一个镜像，该镜像在删除时会删除 cinder 上传卷到镜像所依赖的 barbican 密钥）。但它引发了一个问题，即我们是否需要检查单个 barbican 密钥是否与多个资源关联（通过在创建时阻止这种情况发生，或者不删除这样的密钥）。

Eric 指出，即使当前 cinder 代码保持资源和 barbican 密钥之间的一对一关系是正确的，用户也可能“破解”工作流程并破坏这种一对一的对应关系，因此我们应该预料到这一点。

Glance 计划等待 Barbican Secret Consumer API 的实现（已在 Train 中批准，预计在 Ussuri 中完成），以解决他们方面类似的问题。

共识是，当新的 Barbican API 可用时，再深入研究这个问题。也许加上数据库中的唯一性约束会更好。

问题在于，无论我们做什么都会有一些限制，因为其他服务（或最终用户）可能会决定将特定的 barbican ID 用于某些用途。因此，即使我们知道 *Cinder* 不再使用该 ID，并且从 Cinder 的角度来看可以删除该密钥，我们也不能确定云中绝对没有任何东西持有对该密钥的引用。

操作

  • rosmaita 记住在 Barbican Secret Consumer API 可用时再次提出这个问题
  • rosmaita 查看我们当前的文档 -- 如果我没记错的话，Glance 和 Cinder Train 版本说明强调 cinder_encryption_key_id 不应该被任何其他东西使用；确保这在常规文档中某个显眼的位置

最近移除的驱动程序的审查

一月份，我们修订了驱动程序移除策略，以便给供应商更多时间来解决第三方 CI 问题（这是驱动程序被标记为“不支持”然后被移除的主要原因）：https://docs.openstack.org/cinder/latest/drivers-all-about.html#driver-removal

以前，一个已弃用并标记为“不支持”的驱动程序将在下一个开发周期中被移除。新的策略是，驱动程序可能会保留在代码库中，具体取决于 Cinder 团队的决定，具体取决于诸如供应商是否正在沟通修复 CI 的努力、它支持的后端是否已经 EOL 等因素。该策略确实规定，一旦驱动程序破坏了 gate，它就有可能被移除。

在一月份修订该策略之前，我们移除了一些受先前策略约束的驱动程序；我们需要弄清楚如何处理这些驱动程序。

以下驱动程序在 Train 中被标记为“不支持”，并在 Ussuri 中被移除。

Datera  <-- being re-supported by the vendor: https://review.opendev.org/#/c/704153/
Huawei Fusionstorage   <-- vendor fixed CI and it is now 'supported' in U
IBM Flashsystem  <-- vendor would like to, but no resources  (leave in)
IBM GPFS   <-- no plan from IBM to support it  (leave in)
IBM Storage XIV  <-- vendor would like to, but no resources   (leave in)
IBM Storage DS8k   <-- vendor fixed CI and it is now 'supported' in U
IBM Storwize    <-- vendor fixed CI and it is now 'supported' in U
HPE LeftHand  <-- product line may has gone EOL; so, remove
Nimble          <-- has been removed in U  --- part of HPE -- find out intention and report back
Oracle ZFSSA  <-- no longer supported (leave out)
Sheepdog        <-- has been removed in U (project no longer active) (leave out)
Prophetstor     <-- has been removed in U    (no response) -> restore
Veritas Access  <-- has been removed in U  (no response) -> restore
Virtuozzo       <-- has been removed in U  (no response) -> restore

以下驱动程序在 Ussuri 中被标记为“不支持”

  • Brocade FCZM 驱动程序
    • 供应商宣布在 Train 之后不再支持（驱动程序仅在 py27 下运行）
    • Gorka 将测试它是否可以在 py36/37 下运行
    • 决定：在 RC 时间之前重新评估；如果确认可以在 py3 上运行，则保留
  • MacroSAN
  • IET iSCSI
    • 项目不再活跃，将在 Victoria 中移除
  • Dell EMC PS Series
    • 产品即将 EOL，将在 Victoria 中移除
  • Veritas Clustered NFS
    • 没有收到供应商的回复


Walt 提出操作员使用这些驱动程序，需要使其可用；即使它们破坏了 gate，也值得保留它们。否则操作员可能会 fork Cinder，然后陷入困境。我们决定在 PTG 上重新讨论这个问题，因为我们现在可能没问题。但我们需要制定一个计划，以应对其中一个驱动程序破坏 gate 的情况。一些可能性

  • 将驱动程序移动到特殊目录
  • 禁用失败驱动程序的单元测试

操作

  • 确保上述注明的驱动程序确实已恢复
  • rosmaita - 再次联系“没有回复”的供应商，以鼓励他们重新运行第三方 CI 并了解他们的意图

升级检查中不支持/重新支持的驱动程序处理

这里的主要问题是，移除驱动程序的补丁通常与将该驱动程序添加到升级检查的补丁是分开的。我们需要在 M-3 时查看，以确保恢复的驱动程序从升级检查器中移除。

操作

  • rosmaita 审查升级检查移除的驱动程序列表

第三方 CI 和“Python 3”

在 Train 版本中推动使用第三方 CI 进行 Python 3 测试期间，我们说过：“由于 OpenStack 的 Train 版本应该支持 Python 3.6 和 Python 3.7，因此可以接受你的 CI 仅运行 3.7，理论上在 3.7 中运行的任何内容也将在 3.6 中运行”（https://wiki.openstack.org/wiki/Cinder/3rdParty-drivers-py3-update）

这不是一个好的推论，但让第三方 CI 运行一个不是其发行版默认的 py3 是一个大问题，所以我们只要求一个，即 3.7。当添加新驱动程序时，问题出现了，它们需要测试哪些运行时？答案是

  • 理想情况下，所有周期 python 运行时
  • 否则，一个周期运行时
  • 但是，他们需要关注每个周期 OpenStack python 运行时 -- 它不会永远是 python 3.6


Luigi 提到第三方 CI 需要确保他们正在运行 cinder-tempest-plugin

Walt 提到有一种简单的方法来启动 zuulv3 和运行 CI 所需的一切：https://01.org/openstack/blogs/manjeets/2019/how-test-open-source-hardware-drivers-zuul-v3-and-docker-compose

这类似于我们一直在向第三方 CI 维护者提到的 Software Factory 解决方案。

操作

  • rosmaita - 确保上述内容在文档中清晰

安全问题不再是安全漏洞

https://bugs.launchpad.net/cinder/+bug/1740950

这个问题已经存在很长时间了，由于 VMT 策略的变化，安全漏洞仅在私下保留 90 天，因此几周前公开了该问题。

Rajat 有一个补丁：https://review.opendev.org/713231

操作

  • 大家 - 审查 https://review.opendev.org/713231
  • rosmaita - 与 VMT 确认他们是否不想对此做任何事情 - 他们基于这是一个 Y 类漏洞（仅存在于开发版本中）做出了“不会修复”的决定，但那是几个周期之前了

第三方 CI 上的 cinder-tempest-plugin

Luigi 提到第三方 CI 需要确保他们正在运行 cinder-tempest-plugin。

还有空间进行更彻底的测试，以便我们能够更确定代码有效，而不仅仅是不出现 500 错误。例如，Rajat 有一个补丁来添加快照数据完整性测试：https://review.opendev.org/#/c/702495/

操作

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