关于 Cinder 驱动程序¶
通用注意事项¶
Cinder 允许您将各种存储解决方案集成到您的 OpenStack 云中。它通过为硬件提供商提供一个稳定的接口来编写驱动程序来实现这一点，从而使您能够利用其解决方案的各种功能。
“受支持”的驱动程序¶
为了方便您评估特定供应商驱动程序的稳定性和质量，Cinder 团队引入了受支持驱动程序的概念。这些驱动程序
具有可识别的驱动程序维护者
包含在 Cinder 源代码仓库中
使用上游 Cinder 的错误跟踪机制
支持 Cinder 所需驱动程序函数
维护一个第三方持续集成系统，该系统在他们的存储设备上运行 OpenStack Tempest 测试套件
必须对每个 Cinder 提交执行此操作，并将结果报告到 OpenStack Gerrit 代码审查界面
有关详细信息，请参阅 驱动程序测试
总而言之，驱动程序被认为是 受支持的 有两个重要方面
代码符合 Cinder 驱动程序规范（因此您知道它应该可以正确地与 Cinder 集成）
驱动程序代码会持续针对 Cinder 的更改进行测试（因此您知道代码实际上可以正确地与 Cinder 集成）
第二点尤其重要，因为 Cinder 的更改可能会以两种方式影响驱动程序
Cinder 的更改可能会引入仅影响特定驱动程序或驱动程序的错误（这可能是因为许多驱动程序实现了远远超出所需驱动程序函数的功能）。借助正常运行并报告的第三方 CI 系统，可以在代码审查阶段检测到此类错误。
Cinder 的更改可能会触发新的代码路径，从而暴露驱动程序中先前未检测到的错误。正常运行的第三方 CI 系统将检测到这一点，并提醒驱动程序维护者存在问题。
新的驱动程序 CI 要求¶
在添加新驱动程序时，对驱动程序及其关联的第三方 CI 系统提出了以下要求
驱动程序属性中的 CI_WIKI_NAME 正确
在 https://wiki.openstack.org/wiki/ThirdPartySystems 下存在 CI wiki 页面
ping 到 wiki 页面中的联系人会收到 pong 响应
重新检查触发功能正常工作
CI 响应新的驱动程序补丁
CI 响应其他 cinder 补丁
CI 响应 os-brick 补丁
CI 运行所有 cinder-tempest-plugin 测试
CI 结果可访问
未能满足这些要求中的任何一项将导致新的驱动程序无法被接受到 Cinder 项目中。
驱动程序合规性¶
当前的 CI 合规性策略是
CI 必须报告每个补丁，无论代码更改是在他们自己的驱动程序代码中还是不是
CI 注释必须正确格式化，才能在 Gerrit 的 CI 摘要中显示
如果
在两周内没有 CI 成功报告
发现 CI 没有测试预期的驱动程序（CI 使用默认 LVM 驱动程序等）
发现其他问题但未及时解决
CI 结果会定期审查，如果发现不合规，则会提交一个驱动程序补丁将其标记为“不受支持”。这可以在开发周期的任何时间发生。一旦 CI 问题得到纠正，驱动程序就可以恢复到“受支持”状态。
我们在每个发布的第三个里程碑附近进行最终合规性检查。如果驱动程序被标记为“不受支持”，供应商有直到第一个 Release Candidate 标签（第三个里程碑后的两周）的时间来合规，在这种情况下，标记驱动程序为“不受支持”的补丁可以还原。否则，该驱动程序将被认为在发布中“不受支持”。
当前的 CI 结果发布在这里：http://cinderstats.ivehearditbothways.com/cireport.txt
“不受支持”的驱动程序¶
当驱动程序不合规时，会被标记为“不受支持”。
这样的驱动程序会将警告消息记录到 cinder-volume 日志中，表明它不受支持且已弃用，即将被删除。
为了使用不受支持的驱动程序，操作员必须在 cinder.conf 的驱动程序配置部分中设置配置选项 enable_unsupported_driver=True，否则 Cinder 服务将无法加载。
如果问题在下一个发布之前没有得到纠正，该驱动程序将符合标准的 OpenStack 弃用策略，并从 Cinder 代码仓库中删除。
如果问题已在下一个发布之前得到纠正，并且维护该驱动程序的团队提交了一个将驱动程序标记为“受支持”的补丁，则该补丁（经 Cinder 稳定维护团队的酌情决定）有资格回移植到最新的稳定分支。
注意
恢复“受支持”状态背后的想法是，在下一个开发周期开始后，驱动程序被标记为“不受支持”后，应该尽早进行恢复。例如，驱动程序在 Victoria 发布中被标记为“不受支持”，但在 Wallaby 开发周期的早期解决了 CI 问题；然后可以将标记驱动程序的补丁提议到 stable/victoria。因此，该补丁将包含在 Victoria 的第一个稳定版本中，并且从 Ussuri 升级到此版本的操作员不必更改他们的配置文件。
请注意“经 Cinder 稳定维护团队的酌情决定”的限定。其原因之一是第三方 CI 系统通常仅在开发分支的更改上运行。因此，如果驱动程序的 CI 在开发周期的早期恢复，并且此时代码更改不多，则在开发分支中 CI 通过可以解释为对最新稳定分支中 CI 的代理。显然，随着开发周期的进行，这种解释变得越来越无效。此外，这种解释不适用于较旧的稳定分支。
驱动程序删除¶
(添加于 2020 年 1 月)
如上所述，不受支持的驱动程序有资格在标记为“不受支持”的发布之后的开发周期中删除。（例如，在 Ussuri 发布中标记为“不受支持”的驱动程序有资格在导致 Victoria 发布的开发周期中删除。）
在 Ussuri 开发周期中，Cinder 团队决定，有资格删除的驱动程序，经团队酌情决定，可以保留在代码仓库中只要它们继续通过 OpenStack CI 测试。当此类驱动程序阻止 CI 检查或门时，将被立即删除。（这不违反 OpenStack 弃用策略，因为此类驱动程序的弃用期始于其被标记为“不受支持”时。）
注意
为什么有“经团队酌情决定”的限定？一些供应商可能会宣布他们无意继续支持驱动程序。在这种情况下，Cinder 团队保留在弃用期过后尽快删除驱动程序的权利。
因此，不受支持的驱动程序可能在被声明为“不受支持”后的多个版本中保留在代码仓库中。操作员应考虑到驱动程序被标记为“不受支持”的时间长度，然后再决定部署不受支持的驱动程序。这是因为随着未维护的驱动程序老化，对其依赖的库和其他软件的更新和错误修复可能会导致驱动程序无法通过单元和功能测试，从而使其受到立即删除的影响。
本次策略修订的意图有两个。首先，它为供应商提供更长的缓冲期，以便进行必要的更改以使他们的驱动程序恢复为“受支持”。其次，将这些驱动程序保留在树中更长时间应该可以方便那些部署了使用被标记为“不受支持”的驱动程序的存储后端的操作员。但是，操作员应记住上述几点，然后再部署此类驱动程序。
当前的 Cinder 驱动程序¶
Cinder 团队维护一个页面，其中包含当前的驱动程序以及它们支持的内容，位于 驱动程序支持矩阵。
您可以在 可用驱动程序 页面上找到有关当前驱动程序的更多详细信息。
此外，每个驱动程序的配置参考提供了更多信息。请参阅 卷驱动程序。
