第三方面驱动程序持续集成测试¶
https://bugs.launchpad.net/ironic/+bug/1526410
本规范旨在定义将第三方面持续集成测试引入 ironic 的截止日期、要求和流程。
问题描述¶
ironic 项目希望确保树中的所有驱动程序都得到维护并且质量很高。为了实现这一目标，除非更改的代码或文档无法影响驱动程序，否则需要所有驱动程序都具有一个持续集成测试系统，以针对 ironic 的每个代码更改测试驱动程序。每个驱动程序测试系统需要运行的所需测试将在 ironic CI 要求文档中记录。并非所有驱动程序都由第三方供应商提供或维护。
第三方供应商必须为他们维护的驱动程序提供并维护此 CI。任何无法实现可靠 CI 系统以进行测试的驱动程序的维护者都将被从 ironic 树中移除。
如果一个驱动程序测试系统在一段时间内持续运行预期的测试并报告测试结果，则该系统将被视为可靠的。测试预计在补丁提交后的 8 小时内完成并报告回 gerrit，直到 Newton 版本的结束，并在 Ocata 开发周期结束前 4 小时内完成。
一个驱动程序测试系统如果
它为每个未排除的补丁集运行预期的测试。排除原因将被记录并由 ironic 团队批准。
它在预期的时间范围内报告结果，如上所述。
所有必需的测试工件都以标准格式发布，并按照基础设施要求[3]向社区提供。
测试结果（通过或失败）准确无误。
提议的变更¶
ironic 团队已决定要求所有驱动程序维护者运行和维护 CI 测试系统，以便他们的驱动程序代码保留在 ironic 源代码树中。当 CI 系统出现问题时，驱动程序测试团队将尽最大努力回答有关其系统的问题并快速修复系统。如果驱动程序测试团队没有响应，则该系统可能被取消投票权限，并最终导致驱动程序从源代码树中移除。
时间表¶
实施并开始强制执行第三方面驱动程序 CI 的流程应在 Newton 开发周期的结束前完成。
可交付里程碑
立即：联系驱动程序团队并通知他们期望。
Mitaka-2 里程碑：驱动程序团队将通过创建系统帐户并确定其 CI 团队的联系人来注册他们运行 CI 的意图。
Mitaka 功能冻结：所有驱动程序系统都显示了接收事件并在第三方面 CI 沙盒中发布评论的能力。
N 功能冻结：每个补丁测试和发布评论。
请参阅 Mitaka 发布计划[5]以获取具体日期。请注意，ironic 项目并不严格遵循官方 OpenStack 发布周期截止日期，但我们使用官方截止日期作为参考点。
Infra CI 将继续测试已经在 gate 中使用的 ssh 驱动程序。
未在 Newton 版本功能冻结之前实施可靠报告 CI 测试系统的第三方面驱动程序团队将被从 ironic 源代码树中移除。错过任何里程碑的驱动程序测试系统可能会立即从源代码树中移除。
驱动程序测试系统最初需要运行类似于 gate-tempest-dsvm-ironic-pxe_ipa 的测试，唯一的区别是更改了加载的驱动程序等，以使 ironic 与被测驱动程序一起工作。
关于此和其他所需测试的更多信息需要进一步的文档说明。
初始驱动程序测试系统将不允许对 ironic 的更改进行投票。只有在 ironic 团队根据测试团队的参与度、可用性和可靠运行历史记录批准后，驱动程序测试团队才能要求其 CI 系统被允许投票。
驱动程序测试系统预计将遵循基础设施第三方面测试要求[3]，除非在此处或在本规范产生的 ironic 第三方面驱动程序测试文档中被覆盖。
驱动程序测试系统必须测试对 master 的补丁，以及自第三方面 CI 开始测试以来创建的分支的补丁。例如，如果 CI 在 Mitaka 周期期间开始测试，那么在 N 周期期间，该 CI 预计将测试对 master 和 stable/mitaka 分支的更改，但不会测试 stable/liberty 分支。
没有 CI 测试的社区维护的驱动程序也将从 ironic 源代码树中移除。
从 Newton 功能冻结开始，所有新的 ironic 驱动程序必须表明他们有一个执行 CI 测试的系统，并满足所有 infra [3] 和 ironic 要求才能将代码放入 ironic 树中。在 Newton 功能冻结之前正在进行的驱动程序在 Newton 功能冻结之前必须满足这些要求。不需要在提出驱动程序规范时展示 CI 测试，但必须在提交代码之前到位。
备选方案¶
无
数据模型影响¶
无
状态机影响¶
无
REST API 影响¶
无
客户端 (CLI) 影响¶
无
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
Ramdisk 影响¶
N/A
安全影响¶
无
其他最终用户影响¶
无
可扩展性影响¶
无
性能影响¶
无
其他部署者影响¶
在升级到删除未测试驱动程序的版本时，如果部署者正在使用从树中移除的驱动程序，他们需要更改为树中的驱动程序，或者如果存在，从新位置安装移除的驱动程序。
Ironic 团队必须沟通哪些驱动程序正在被移除，以及何时移除。我们应该注意到，这些驱动程序可能在新的位置可用，并且驱动程序作者可能正在沟通这些信息。
从树中移除的驱动程序的作者可以沟通新的位置（如果存在），并记录如何在 ironic 环境中安装该驱动程序。
开发人员影响¶
开发人员的影响可能包括核心审查者需要在系统测试完成之前等待才能批准补丁进行合并。测试失败的开发人员需要查看与其补丁链接的测试工件，以及补丁评论日志中留下的评论。如有必要，开发人员可能需要与驱动程序测试团队协调，以获得调试问题的帮助。请参阅下面的参考文献中的基础设施要求。
实现¶
负责人¶
- 主要负责人
krtaylor
- 其他贡献者
jroll, thingee
工作项¶
与树中现有驱动程序的供应商沟通 - 尽合理努力联系负责驱动程序的实体，并告知他们需要驱动程序第三方面 CI 的时间表。
设置供应商实施 CI 测试的增量时间表里程碑。
需要记录一个弃用流程。
记录流程、要求 - 本规范并非旨在详尽列举所有要求，只是为了定义需要记录它们。
文档还需要描述测试系统如何证明他们正在充分测试他们的驱动程序。
汇编并维护树中所有驱动程序的联系人列表。
根据上述时间表移除未实施 CI 测试系统的第三方面驱动程序。
记录对 ironic 部署者和开发人员的影响，即他们可能使用的驱动程序已被从树中移除，如部署程序影响部分所述。
依赖项¶
无
测试¶
如本规范所述。
升级和向后兼容性¶
使用从树中移除的驱动程序的部署者将面临重大的升级影响；有关更多信息，请参阅“部署程序影响”部分。
将记录一个弃用流程，包括时间表。
文档影响¶
会有多个方面受到影响
记录树中的驱动程序及其预期功能。
记录第三方面驱动程序系统的要求、期望、时间阈值、需要运行的测试以及其他必要的主题。
记录第三方面测试系统基础设施的示例实现。
记录通知社区和用户驱动程序将被从树中移除的流程。
记录有关所需测试的更多信息
参考资料¶
[1] 第三方面 CI 工作组 https://wiki.openstack.org/wiki/ThirdPartyCIWorkingGroup
[2] 第三方面 CI 会议 https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] 实施第三方面系统的基础设施要求 https://docs.openstack.org/infra/system-config/third_party.html#requirements
[4] Mitaka 首脑会议讨论 https://etherpad.openstack.org/p/summit-mitaka-ironic-third-party-ci
[5] Mitaka 发布计划：https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
