CinderUssuriPTGSummary
目录
- 1 简介
- 2 星期四(上海)
- 3 星期五(上海)
- 4 星期一(虚拟)
- 5 星期三(虚拟)
简介
此页面包含在 2019 年 11 月 7-8 日在中国上海举行的 Ussuri PTG 期间涵盖的主题的摘要。它还包含在 2019 年 11 月 25 日和 27 日举行的虚拟 PTG 的摘要。
会议已录制。录音链接位于下方的适当位置。
完整的 etherpad 和所有相关说明可以在这里找到
- 上海:https://etherpad.openstack.org/p/shanghai-ptg-cinder
- 虚拟:https://etherpad.openstack.org/p/cinder-ussuri-virtual-ptg-planning
查找所有者的行动项的 etherpad 在这里:https://etherpad.openstack.org/p/cinder-ussuri-ptg-actions
星期四(上海)
Cinder 项目入职和“认识 Cinder 开发人员”环节
所有参加者都 100% 满意,并对 Cinder 赞不绝口。不幸的是,没有人参加,所以我们花时间弄清楚如何连接和定位录音设备。
Python 2 支持及移除 Py27 支持的剩余工作
我最初的观点是,我们需要在 master 中保留 Python 2 测试一段时间——至少在仍然支持稳定分支中的 Python 2 的情况下,因为否则回溯会成为一个大问题(如果补丁中使用任何 py3 专用语言特性,将无法进行干净的回溯)。几乎没有人同意这个观点。
Sean 指出,随着库停止对 py2 的支持,我们无论如何都无法在 py2 测试中使用它们。Ivan 和 Sean 迫不及待地想开始删除 py2 兼容代码。Gorka 认为修改回溯的额外工作量不会太大,而且如果我们真的要开始使用 py3,不如现在就开始。
行动
- 提醒审阅者:我们需要非常仔细地检查测试用例的代码覆盖率,以便新代码具有出色的覆盖率,并在稳定分支中提出回溯时很可能失败。
- 提醒提交者:在审阅者要求更多测试时,请耐心一点!
- 提醒社区:新功能可以使用 py3 语言结构;可能需要回溯的错误修复应该更保守,并为 py2 兼容性编写。
- 提醒驱动程序维护者:^^
- Ivan 和 Sean 已获得开始删除 py2 兼容性的许可
策略迁移
一些背景信息:https://etherpad.openstack.org/p/policy-migration-steps Keystone 添加了默认的只读角色和服务范围的角色,但它们在项目编写使用它们的策略之前不会执行任何操作。oslo.policy 代码有一种定义默认策略 + 已弃用默认策略的方法;在弃用期间,最宽松的策略获胜。这将允许运营商轻松迁移到新策略。
仍然存在关于如何设置这些测试的问题。Keystone 仅进行了单元测试,但测试非常重量级;每次都必须在 DB 中设置所有用户;他们希望他们能用 tempest 来做这件事。但也有人担心,在 tempest 中这样做可能不切实际。(这可能取决于项目。)
将启动一个弹出团队,以帮助将更大的项目迁移到新的策略代码。
行动
- rosmaita 将调查不同的测试方法。注意:可能 tempest 会添加创建不同用户的方法,而不同的项目将不得不使用这些方法进行自己的测试。
- rosmaita 将研究范围选项并了解对 Cinder 的影响。
- 需要创建一个我们策略和不同范围的矩阵。
- 需要弄清楚管理上下文如何适应
- 需要检查当前的测试覆盖率以及需要增强测试的地方。
- 不必让一个人来做。可以分工合作。
- rosmaita 和 e0ne(以及任何对此感兴趣的人)加入弹出团队以获取更多信息并帮助 Cinder 起步。
Cinder V2 API 移除
我们现在无法直接删除 V2 代码(例如,V2 扩展需要移动到 V3),但我们可以删除对 API 的访问。不过实际上也不完全是这样,在删除 V2 API 之前,还需要做很多准备工作
- Tempest 仍然假设 V2 API 存在。需要修复它。
- OpenStack Client 也有一些 V2 API 假设。
- Devstack 也无法正常工作。
Sean 有一个补丁来查看删除 V2 后情况会变得多么糟糕:https://review.opendev.org/554372
V3 与 V2 几乎完全相同。我们应该能够更改并让人们切换端点即可工作。如果我们可以更新目录,那就太好了,但似乎并非如此。
行动
- 在虚拟 PTG 中跟进此项。我们用 Sean 的补丁发现了什么?
- 创建一个需要完成的具体工作项列表。
- 那时我们也许可以将工作分配给实习生(如果有实习生)。
Cinder REST API V4
我们在温哥华谈到了在积累了足够多的微版本后,达到可以迁移到 V4 的时间点。
行动
- 我们不需要在本版本中这样做(让我们先删除 V2),但我们需要将其牢记在心,作为未来的目标。
Volume 本地缓存
需要 Cinder 和 Nova 的工作
- Cinder 规范:https://review.opendev.org/#/c/684556/
- Nova 规范:https://review.opendev.org/689070
目前有不同类型的快速 NVME SSD,例如 Intel Optane SSD,其 r/w 通量可以达到 2.x~3.x GB/s,延迟可以达到 ~10 us。而为 VM 的典型远程卷可以是数百 MB/s,延迟可以是毫秒级(iscsi / rbd)。因此,这些快速 SSD 可以安装在计算节点本地,并用作远程卷的缓存。对于存储团队,我们需要在 os-brick 中添加支持。
共识是:有些存储解决方案无法实现这一点(Ceph,主机上没有挂载点),有些可能不需要这样做(一些供应商已经拥有超快速缓存),有些值得这样做,因此总体感觉支持这项工作。
有关详细信息,请参阅 PTG etherpad。讨论期间使用的翻转图的图片:https://twitter.com/jungleboyj/status/1192323512238776320
行动
- Liang Fang 将继续进行这项工作
可变选项
这篇文档的背景是 NetApp 客户的一个需求,他们希望能够在不重启任何服务的情况下更改后端凭据。
目前的问题是,可变配置可以针对 REST API 完成,但并未超出该范围。此外,更改驱动程序凭据的工作量稍大,因为可能需要重新加载驱动程序,或者所有驱动程序都需要一种机制来识别和处理该更改。另外,我们不希望在驱动程序之间共享的可配置选项是可变的。
Gorka 指出,支持主动-主动模式的驱动程序不需要为此目的使用可变选项。 采用主动-主动模式而不是以这种方式刷新凭据会更好。 A/A 高可用性支持已经准备了几个版本,但到目前为止,只有 RBD 驱动程序进行了测试和启用。
团队认为使用主动/主动模式是最佳方案。
行动
- Gorka 自愿支持 NetApp 团队,如果他们选择实施 A/A 模式。
- 需要在开发者文档中添加说明,仅仅在 oslo.config 中使一个选项可变并不能解决驱动程序的问题(更多信息请参见 etherpad)。
与 Edge 工作组的跨项目讨论
显然,TripleO 的下一个版本将支持边缘存储。他们想知道我们是否了解相关信息。我们不了解。
就边缘持久存储而言,电信公司考虑只使用 NFS,并将其放在核心中——这是一个令人担忧的概念。
在考虑边缘用例时,了解人们设想的物理限制非常重要。例如,一个小的电信机架,或者一个带有空调的小型数据中心,或者一个带有空调和更大存储单元的更大的数据中心等等。你真的无法谈论“边缘”(在这里插入 U2 的笑话)。
更多信息请参见 etherpad。
根据项目或用户默认卷类型
拥有单个默认卷类型对于拥有多个可用区和许多租户/项目的更大的云来说限制性太强。操作员希望在特定情况下使用更多默认值。
选择使用哪个默认值很容易;这项工作的难点在于代码,它需要在最终用户/项目级别启用默认值的创建。需要
- 新的 API 调用(创建、显示、列表、更新、删除)、新的微版本
- 客户端支持
- 告知 Horizon
行动
- geguileo - 编写规范
- 来自 Glance 的请求:我们可能还需要一个每个服务的默认值(当传递服务令牌时触发)。
Cinder retype 不使用驱动程序辅助迁移
Gorka 认为这不依赖于驱动程序;他认为它对所有驱动程序来说都是错误的。 管理器中的代码阻止了高效路径的执行:https://github.com/openstack/cinder/blob/ca5c2ce4e8ae9fbc92181ac4ba09cec3429a71e6/cinder/volume/manager.py#L2490 曾经有理由这样做;我们需要审查并查看它是否仍然成立。
Ivan 认为这只是一个错误。虽然我们还没有为此打开一个错误报告。
行动
- e0ne 将调查并修复它(如果他可以验证它是错误的)。
结束一些当前打开的分支
我们有 8 个打开的分支加上 master (ussuri)。我向 ML 发送了一封电子邮件,要求提供数据,以便我们能够做出关于此的良好决策:http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.html
没有收到任何回复,显然社区并不认为这是一个重要的问题。
该策略是,我们需要提前 6 个月宣布计划结束一个分支。这允许供应商介入并接管它(如果需要)。因此,如果我们想删除分支,我们只需要宣布计划结束分支,然后在 6 个月后执行即可。
driverfixes 分支已经有一段时间没有使用了。
- 我们应该删除它们吗? 不,我们真的不想丢失这些提交的历史记录。
- 我们可以重命名它们吗? 在标题中添加“archived”(已归档)或类似内容,以明确它不再接受代码。(或者只是记录它们是旧驱动程序修复的存档。)
- 当我们结束一个驱动程序时,我们应该将其变成一个 driverfixes 分支。(关于这里提出的内容不太清楚,需要在 VPTG 中跟进。)
行动
- rosmaita - 从 infra 团队了解有关重命名分支的信息;以及关于只读分支的信息(更改为 gerrit,以便无法向该分支提交补丁)?
- 提议:结束 o, p 并将它们重命名为 archived-ocata, archived-pike
- rosmaita - 向 ML 发送提议,说明 o, p 将在 6 个月后退出 EM 状态
- 在虚拟 PTG 中重新讨论
- EOL 策略最近已修订,不再需要 6 个月的等待期。
- 希望重新考虑是否删除 EOL 分支是一个好主意,如果我们不打算向它们合并任何内容。
讨论最新的用户调查结果
这里有一个仅包含 Cinder 回复的便捷列表:https://etherpad.openstack.org/p/cinder-2019-user-survey-question-responses
行动
- 复制需要更好的文档,以便人们知道我们可以正确地故障转移和故障恢复。
- ivan 计划继续进行通用的备份驱动程序工作。
与 Nova 团队的会议
当我们在 Cinder 中故障转移时,卷在 Nova 中将无法使用,但我们没有告知 Nova 故障转移已发生。 Nova 中需要执行的任何纠正程序都需要手动完成。 如果我们让 Nova 知道已发生故障转移,以便他们可以采取行动,那会更好。
一个复杂之处在于,Nova 无法简单地分离和附加卷,因为飞行中的数据将会丢失。
那么引导卷呢? 在这种情况下,实例已经死了,因为无法访问该卷。 可以通过关闭、分离、附加、重新启动的路径。 问题是分离将会失败。 需要强制执行或处理失败。 但我们不确定 Nova 是否允许分离引导卷。 而且我们目前没有强制分离的 API。
还讨论了有关从加密卷创建的镜像的 Nova 错误:https://bugs.launchpad.net/nova/+bug/1852106,但尚不清楚该错误中描述的场景是否真的会发生。
行动
- 需要弄清楚如何将强制传递给 os-brick 以分离卷并在重新启动卷时使用。
- rosmaita 调查 Bug #1852106
星期五(上海)
与 Glance 团队的会议
Cinder 中支持 Glance 多个存储
参考:(cinder 规范)https://review.openstack.org/#/c/641267/
Cinder 团队仍然同意这个想法(已获得 Train 的批准)。
行动
- 将规范重新定位到 Ussuri
- 让 Abhishek 的补丁得到审查
镜像快照共置
对于边缘用例,Glance 计划使用 Nova 提供的关于服务器从哪个镜像引导的信息,将该服务器的快照与原始镜像存储在同一存储中。 希望对作为镜像上传的 Cinder 卷也这样做。 只需要一个标头来指定正在上传的卷的“基础”镜像。 我们同意这是一个与上述不同的用例。
行动
- Abhishek 将编写 Cinder 的规范
Glance Cinder 驱动程序非常有限
我们认为它只使用默认卷类型,而且测试也不充分。 我们都同意这是一个令人遗憾的情况。
行动
- 有人应该做点什么
与 Horizon 会议,讨论他们提出的 Cinder 用户消息实现方案
Horizon 有兴趣公开 User Messages API。 我们同意这是一个好主意。
有一个问题是消息是否以请求的语言显示。 也许这已经在 REST API 层通过“Accept-Language”标头处理了。 如果没有,那么这可能是支持它的地方。
行动
- rosmaita 确定这是否需要更改 API 代码,或者现有代码是否已经处理了这个问题。
附加/分离速度
Gorka 想知道 OpenStack 中是否有关于附加/分离速度的投诉,特别是由于人们现在使用 Cinder 为 Kubernetes 提供卷(cinder in-tree 驱动程序、Cinder-CSI、Ember-CSI),并且可能会看到更多的附加/分离请求。
每个人似乎都对此感到满意,只有 geguileo 在抱怨。
行动
- 目前不是一个问题
Train 中期周期主题:状态和延续到 Ussuri
Train 中期周期的说明:https://wiki.openstack.org/wiki/CinderTrainMidCycleSummary
中期 etherpad:https://etherpad.openstack.org/p/cinder-train-mid-cycle-planning
多重附加
所有项目都需要跟进。 目标是
- 短期:记录一些关于如何测试此功能的指导
- 长期:在 cinder-tempest-plugin 中添加一些新的测试
行动
- rosmaita 撰写短期文档
iSCSI Ceph 驱动程序
由于一些下游优先级的变化,Walt 很难找到时间来处理这个问题。 Ivan 建议 Walt 发布他所拥有的任何内容,即使它不能工作,这样他所学到的东西就不会丢失。 有一些补丁和一个 github 仓库,其中包含 Walt 必须编写的一些代码,这些代码在 OpenStack 或 Ceph 中没有家。
行动
- rosmaita:跟进 Walt
- rosmaita:创建一个 etherpad,其中包含到目前为止所做工作的链接
第三方 CI 异常
后端供应商对其驱动程序代码进行第三方测试对项目非常重要。 但大多数第三方 CI 似乎都非常不稳定。
对于大多数供应商来说,在 Train 中将他们的第三方 CI 更新为运行 python 3.7 并非易事。 如果我们可以为他们提供关于如何设置和维护第三方 CI 的更好指导,那将很好。 我们也希望供应商运行 cinder-tempest-plugin,但除非我们可以使路径更轻松,否则我们不想提出要求。(顺便说一下,Datera 正在他们的 CI 中运行 cinder-tempest-plugin!)
第三方 CI 文档(部分列表)
- https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
- https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
- https://docs.openstack.org/infra/system-config/third_party.html
- https://docs.openstack.org/cinder/latest/contributor/drivers.html
行动
- Luigi 有一些关于使用 RDO Software Factory 作为第三方 CI 的基础的想法;需要与他跟进。
- Gorka:将检查 RDO 有什么可用资源
- e0ne:将查看谁在使用 cinder-tempest-plugin
- 团队:在 gorka 和 e0ne 报告后,重新组织和更新第三方 CI 文档
改进自动化测试覆盖率
我们希望通过 cinder-tempest-plugin 来实现这一点。 Sophia (enriquetaso) 正在指导一个 Outreachy 实习生,他已经开始进行这项工作。 Eric 一直在编写错误报告,以建议需要解决的测试用例。
SQLAlchemy 到 Alembic 迁移
没有进展。 我们提出了一项夏季实习计划,希望能够获得实习生来完成这项工作;也许我们能成功。
请参阅 https://etherpad.openstack.org/p/cinder-train-ptg-planning(第 247 行)了解更多信息。
功能报告
操作员需要阅读供应商的手册,以了解对于特定的后端,他们可以编写哪些额外的规范,以及它们用于什么。 如果驱动程序能够以操作员可以通过 CLI 找出这些信息的方式报告其功能,那将会很好。
每个人都同意我们仍然想这样做。 这将需要 API 更改,并且已经有一个规范:https://review.opendev.org/#/c/655939/1/specs/train/backend_capabilities.rst
行动
- 在虚拟 PTG 中重新讨论,并找出谁有兴趣参与其中
Cinder 业务
Cinder Ussuri 优先级
我们将在虚拟 PTG 之后最终确定此列表,但这是初始列表
- 增加测试覆盖率
- 增加运行 cinder-tempest-plugin 的 CI 的数量
- 更好地支持第三方 CI:通过提供一种部署稳健系统的途径来简化他们的工作
- 每个用户/项目/服务令牌的卷类型
- 更好的文档
- 通用备份
- 改进 HA 主动-主动文档
- 希望使其更易于测试
- 删除 V2 API
- 删除 python 2 支持
Cinder-core 更新
请参阅 http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010519.html 我们目前的审查强度与 Train 相当。
会议时间变更更新
我们一直等到峰会之后,以便新贡献者可以参与投票。 我们将在 Cinder 每周会议上考虑 Liang Fang 最初提案中的选项:http://eavesdrop.openstack.org/meetings/cinder/2019/cinder.2019-10-23-16.00.log.html#l-166 这些是提前 1 或 2 小时移动会议时间。 邮件列表中也有一些讨论:http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010328.html
行动
- rosmaita 准备一个社区投票
虚拟 PTG
我们讨论了应该采用的格式。 共识是在连续的 2 天内进行,每天使用 2 小时。 这应该使人们更容易参与会议的至少一部分内容。 我们希望尽快进行;共识是在 KubeCon 之后的一周,以避免冲突。 因此,这将是 11 月的最后一周。
行动
- rosmaita 准备一个社区投票,以确定日期/时间
虚拟中期周期
有人对举办中期周期感兴趣。 虽然每个人都认识到面对面交流是最好的,但贡献者们很难获得差旅支持。 因此,我们决定为 Ussuri 进行完全虚拟的中期周期会议。 我们决定在确定虚拟 PTG 的工作方式后,再确定格式。
星期一(虚拟)
论坛会议回顾:您在使用升级检查吗?
Jay 快速回顾了论坛会议。 上面的 etherpad 中有很多行动项。 它们目前分配给 jungleboyj 作为 TC 行动。
仍然有一些问题是 (a) 操作员如何使用这些,以及 (b) 我们应该从开发方面提供哪种类型的检查。 Cinder 团队将其视为预检查。 其他人认为这是一个在升级过程中使用的检查,以确保在操作员启动服务之前一切准备就绪。 预检查对我们来说似乎很有意义;Sean 提到我们可以将一些预检查添加到 cinder-status 命令中。
那么 Cinder 团队在 Ussuri 周期内应该做什么(在我们解决上述问题之前)? 至少,我们仍然应该在驱动程序不受支持且有删除风险时添加它们
- 告知操作员,为了使用不受支持的驱动程序,必须在 cinder.conf 中设置一个标志
- 告知操作员,他们需要联系供应商,了解他们是否有计划重新启用驱动程序;否则,操作员需要准备在下一个 Cinder 版本中将受影响的卷迁移到具有受支持驱动程序的后端
行动
- jungleboyj - 在邮件列表中发起讨论,了解是否有人实际在生产环境中使用或使用过升级检查
- 需要确定这份文档的归属位置
快照共置
该规范如下:https://review.opendev.org/#/c/695630/
这与 Cinder 中 Glance 多存储支持相关,但规范需要更仔细地说明使用场景。我们的想法是:用户有一个从 Glance 镜像创建的卷,并希望将其上传为镜像;希望提供 Glance 信息,以便 Glance 可以将新镜像放在与原始镜像相同的存储中。(因此,此处使用“快照”一词可能不准确。)
此功能依赖于 Glance 多存储规范的另一个实现:https://review.opendev.org/#/c/661676/
行动
- Rajat, Abhishek - 更新规范
移除 Python 2 支持
简要总结了我们在上海讨论的内容(见上文),以便我们保持一致。
现在有一个补丁正在移除 Cinder 中的 py2 测试:https://review.opendev.org/695317。一旦获得批准,将对其他组件执行相同的操作。
关于 Cinder 开发人员使用 Python 3 语言功能的通用建议:https://wiki.openstack.org/wiki/CinderUssuriPTGSummary#Actions
行动
- rosmaita - 合并测试/门禁补丁,然后让好事情发生
用户消息
对在 https://review.opendev.org/#/c/694954/ 上讨论的“admin action 泄漏”问题进行快速讨论
共识是有用的是在用户消息中公开面向管理员的操作,只有管理员才能查看。也许在创建消息时设置一个特殊标志,然后使用管理员上下文来决定是否显示它。同意消息内容与我们目前所拥有的相同(也就是说,即使对管理员也不要公开任何敏感信息)。我们可以等待管理员面向用户消息被使用,并获取有关是否需要更多信息的反馈。
Ivan 指出此更改不需要新的微版本,因为没有更改用户消息 API,也没有更改当前响应。
行动
- rosmaita - 撰写规范
第三方 CI 不规则性
我们想要解决的问题是第三方 CI 系统似乎很不稳定。我们希望能够提供一些更多的支持,使基础设施更加可靠。Luigi 建议使用 RDO Software Factory 作为第三方 CI 的基础。
参考文献
行动
- Luigi - 与 RDO 团队跟进,并获取有关此场景可行性的反馈
- e0ne - 将查看谁在使用 cinder-tempest-plugin
扩展默认卷类型支持给租户
上海讨论的快速回顾(见上文)。Simon 提到他可能有 Pure 的开发人员对此实现感兴趣。Rajat 志愿帮助支持该实现。
行动
- Gorka - 撰写规范
- rosmaita - 与 Simon 沟通
配额!
Eric 有一个补丁可以修复许多问题之一:https://review.opendev.org/#/c/695096/ Eric 认为如果有人感兴趣,可以优化该补丁。
一般问题是,我们更新多个表,并且可能(并且确实)存在竞争条件,最终导致奇怪的情况,例如负配额值或同一项目的多个配额。操作员发布了一些脚本,偶尔用于清理数据库,但最好在 Cinder 中修复此问题。
EOL for driverfixes/{m,n} and stable/{o,p}
自上海讨论以来,已经合并了一个补丁,该补丁删除了从 EM 到 EOL 的 6 个月等待期:https://review.opendev.org/#/c/682381/
上周在 #openstack-tc 中对此进行了讨论:http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-11-22.log.html#t2019-11-22T15:35:01
共识是我们应该继续这样做。
行动
- rosmaita - 在 ML 上发送通知,说明我们将在一周内执行此操作
- rosmaita - 提出一个发布补丁来 EOL 这些分支
驱动程序支持矩阵
上海讨论的后续。有人建议将多路径作为支持矩阵中的一个特定类别。
共识是多路径更多的是后端的特性,而不是驱动程序的特性。了解驱动程序是否支持它很有用,但它不像复制那样是驱动程序是否支持的东西。此外,需要在 nova 中设置一些选项才能使其有用 - nova:libvirt:use_volume_multipath。因此,似乎没有必要将其添加到支持矩阵中。
星期三(虚拟)
v2 API 移除更新
外部问题
- Sean 的补丁删除了“versions”响应中的 v2,出现了一些奇怪的故障(但 Rajat 认为可能有一个快速修复)。
- 现在,devstack 期望同时提供 v2 和 v3,并在服务目录中为两者创建端点:https://opendev.org/openstack/devstack/src/branch/master/lib/cinder
- 另一方面,看起来 tempest 已经准备好 v3:https://review.opendev.org/#/c/530702/
- 此外,Ivan 确信 Horizon 仅使用 v3。
- 我们应该通知 Nova 和 Glance,以确保它们不依赖于 v2 的任何内容。
内部问题
- 我们应该能够清理 v3 从 v2 继承的内容
- 我们可能无法清理 v2/contrib 内容,因为依赖于微版本
行动
- Rajat 尝试修复 Sean 的补丁
- rosmaita - 处理 devstack 内容(服务目录)
- 我们将对 tempest 保持乐观
- rosmaita - 向 ML 发送一封通用邮件,说明我们计划这样做
论坛会议回顾:您如何使用 Cinder 的卷类型?
会话 etherpad:https://etherpad.openstack.org/p/PVG-how-using-cinder-volume-types
Sean 提到了一些论坛会议的亮点。
- NECTAR 正在运行一个补丁,该补丁允许将卷类型分配给 AZ:https://github.com/NeCTAR-RC/cinder/commit/d5a3d938a8e0934d31b5a3c568846b3d32843866
- 有人询问 RBD 是否支持卷在线迁移
- 操作员对在 Rocky 中实现的“支持基于操作类型的后端过滤器”规范感兴趣,但需要一些文档来解释如何使用它。实现是 https://github.com/openstack/cinder/commit/e1ec4b4c2e1f0de512f09e38824c1d7e2fa38617
行动
- e0ne 计划对 RBD 卷迁移进行一些测试
- 需要有人来编写“支持基于操作类型的后端过滤器”的文档
Ceph iSCSI 工作
这对 Ironic 来说是一个重要的功能。有一个 etherpad 收集了 Walt 在这方面所做的工作:https://etherpad.openstack.org/p/cinder-ceph-iscsi-driver
行动
rosmaita - 与 Walt 沟通他的带宽,并要求他将缺失的内容添加到 etherpad 中
Ussuri 社区目标
目标 1:删除 Python 2.7 支持 - 我们将分两个阶段执行此操作。第一阶段是删除 python 2 检查和门禁作业,这样我们就不会依赖任何 py27 在门禁中。第二阶段将是进行更改,以便仅允许使用至少 py36 安装 Cinder。这将在一月份左右进行,届时任何需要为自己的测试以 py27 安装 Cinder 的项目都已删除了该依赖项。
删除 py2 测试的 cinder 补丁是 https://review.opendev.org/#/c/695317/ - 一旦合并,我们将对 os-brick、cinderclient、brick-client-ext 和 cinderlib 执行相同的操作。
目标 2:项目特定的新贡献者和 PTL 文档 - 该目标尚未获得批准;它处于正式投票阶段:https://review.opendev.org/#/c/691737/。根据补丁上的评论,期望当前的 PTL 将在以前的 PTL 的帮助下完成此操作。幸运的是,我们有 2 位仍然积极参与该项目的以前的 PTL。目前公开的问题是文档应该在所有项目之间保持一致,但尚未为此提供模板。
有一个预先选择的目标 V 是迁移所有遗留 zuul 作业:https://review.opendev.org/#/c/691278/。gmann 有一个补丁正在将我们的遗留作业(grenade)移动到 cinder 仓库并使其成为 py3:https://review.opendev.org/#/c/695787/。在某个时候,我们需要将它们转换为真正的 Zuul v3 作业。Luigi 在 etherpad 上留下了一堆关于这些活动的移动部件的信息,并指出欢迎审查。
看起来另一个 V 目标将是“一致且安全的默认策略”目标,该目标在 ML 上发布:http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010291.html。现在正在组织一个“策略弹出团队”来在本周期内完成一些工作:https://review.opendev.org/#/c/695993/
行动
- 每个人 - 关注“删除 py2 支持”补丁
- 每个人 - 欢迎审查 https://review.opendev.org/#/q/status:open+branch:master+topic:grenade_zuulv3
备份服务测试
这是 Train 中期周期的后续。备份测试会间歇性地超时失败。现在的情况是 cinder 备份测试已从 tempest-full 中删除,但它们正在使用 tempest-integrated-storage 运行(这意味着故障会影响我们,但不应阻止其他项目)。该问题仍然需要一些调查;Eric 在 etherpad 上提出建议,以查找 c-bak 日志中的特定 IOError 而不是查找超时。
Eric 还指出测试作业运行时间过长,并且出现无用的消息 - 它们会查找卷变为活动状态,但没有注意到它处于错误状态,应该更快地失败。快速失败可以节省一些门禁资源。也许有人想跟进类似 https://review.opendev.org/#/c/565766/ 的内容?
行动
- 任何感兴趣的人 - 跟进此问题
- rosmaita - (在此讨论中出现,但与此主题无关)使用无损翻译指令更新 etherpad(获取 etherpad 的只读链接,并在可写入的 etherpad 中而不是在可写入的 etherpad 中使用翻译工具)
周期优先级
增加测试覆盖率
我们希望在 cinder-tempest-plugin 中获得更彻底的测试。Sofia (enriquetaso) 正在指导 Outreachy 实习生 Anastasiya (anastzhyr),她将在实习期间专注于此(2019 年 12 月 3 日至 2020 年 3 月 3 日)。Cinder 社区可以通过 (A) 编写标记为“test-coverage”的错误,其中包含可以添加的特定测试想法,以及 (B) 及时审查 Anastaiya 的补丁来协助此工作。
增加运行 cinder-tempest-plugin 的第三方 CI 的数量
这应该很容易™对于当前的第三方 CI 来说(实际上可能已经是要求)。需要获得现在运行它的基线数量。
更好地支持第三方 CI
我们希望通过提供一种标准的方式来部署强大的系统来使他们的生活更轻松。这可能可以使用 RDO Software Factory。Luigi 已经在 RDO 会议上提出了这个问题,RDO(和 SF 人员)支持这个想法:http://eavesdrop.openstack.org/meetings/rdo_meeting___2019_11_27/2019/rdo_meeting___2019_11_27.2019-11-27-15.00.log.html#l-76
WIP 第三方 CI 文档部分用于 SoftwareFactory
- https://softwarefactory-project.io/r/#/c/17097/
- https://softwarefactory-project.io/logs/97/17097/2/check/sf-docs-build/ae24483/docs-html/guides/third_party_ci.html
默认卷类型增强
Gorka 正在编写一个规范,为每个用户/项目/服务令牌提供默认卷类型;基本想法是 PTG 上讨论的内容(见上文)。相关的是改进卷类型文档。
通用备份
相关补丁
改进主动-主动 (HA) 文档
我们预计操作员希望以 HA 模式(Cinder 主动-主动)运行 Cinder。目前 RBD 支持以 HA 运行。
驱动程序必须设置一个标志才能以主动-主动模式运行服务。但除了设置标志之外,对于该驱动程序来说,该功能实际上也应该能够工作。问题是您需要做的事情非常依赖于驱动程序。我们没有 tempest 测试来验证驱动程序是否可以以 HA 运行(但如果它们失败,应该可以添加测试,以便您知道 HA 没有发生)。
我们需要面向两个受众的文档
- 驱动开发者:希望明确为了实现主动-主动模式并声明 HA 支持,您需要做什么。应该能够提供一些通用建议(例如“注意连接上的竞争条件”)来帮助实现和测试您的驱动程序是否支持主动-主动模式。
- 操作员:需要提供一些关于如何在主动-主动模式下部署 Cinder 的建议(例如,您应该有 3 个 API 节点、3 个调度器节点、3 个卷服务)。
移除 v2 API
至少应该能够将其从服务目录中移除,并移除运行它的选项(以及移除不运行 v3 的选项),以便从外部角度来看,可用的只有 v3 API。从 API 中移除所有 v2 代码的重构不必立即发生。
移除 Python 2 支持
这是一个社区目标(而且看起来我们很可能在周期早期实现它)。
迁移到 alembic,不再使用 squlalchemy
我们正接近不得不这么做的时刻。
我们是否应该举行虚拟中期会议?
周期计划:https://releases.openstack.org/ussuri/schedule.html
共识是应该举行 Ussuri 中期会议,并且应该是虚拟的。在讨论时间安排(靠近规格冻结?还是靠近 M-2)时,Eric 指出,如果我们使用与本次虚拟 PTG 相同的模式,即在几天内分散的 2 小时会议,由于我们不需要安排任何物理设施,因此会议不必紧密相连。因此我们可以灵活地在任何有意义的时候安排 2 小时会议。
目前,安排 2 小时虚拟会议的合适时间是
- 在 Cinder 规格冻结期间。规格冻结在 1 月的最后一周,是第 15 周,正好是周期的中间。也许在会议前一周举行虚拟会议,以便未合并的规格可以进行一些讨论(如果需要)?
- 在“Cinder 新功能状态检查点”(2020 年 3 月 16 日当周),这是最终客户端库发布前 3 周。
行动
- rosmaita - 在每周会议上征求更广泛团队的反馈,并组织投票以确定星期几和时间。
