Networking-sfc 评分卡

Neutron 集成

  • N0. 该项目是否使用 Neutron REST API，还是依赖于专有后端？

    Networking-sfc 在 Neutron 核心框架之上实现了自己的一组 Neutron API 扩展，并且它通过服务插件模型来实现。暴露的 API 具有开源实现，并为多个后端提供了一个可插拔的驱动机制。

  • N1. 该项目是否集成了/使用了 neutron-lib？

    是。它仅导入了约 10% 的与 neutron 相关的导入内容。没有定期任务来针对 neutron-lib master 的更改进行测试。

  • N2. 项目成员是否积极贡献以帮助 neutron-lib 实现其目标？

    否，没有明确的证据。

  • N3. 项目成员是否与核心团队合作，通过帮助定义模块化接口，使子项目能够松散地与 Neutron 核心平台集成？

    团队成员帮助审查了一些与 L2 扩展相关的规范和补丁。

  • N4. 该项目如何提供网络服务？它是否使用核心平台提供的模块化接口？

    是，最近团队才成功淘汰了他们所依赖的 OVS agent 分支。

  • N5. 如果该项目提供新的 API 扩展，是否已经讨论并接受了这些 API 扩展，并由 Neutron 驱动程序团队批准？如果需要，请提供 API 规范的链接。

    该项目目前暴露两个 API：流分类和端口链，两者都通过两个独立的服务插件实现。项目启动时，Neutron 团队对后者提供的监督很少。

文档

  • D3. 该项目是否具有 releasenotes tox 目标，功能正常且持续运行？请提供证明。

    否。

持续集成

  • C1. 该项目是否具有显示所有可用作业的历史趋势的 Grafana 仪表板？请提供证明（指向 grafana.openstack.org 的链接）。

    否。

  • C4. 该项目是否具有全栈覆盖率的 CI？

    否。

  • C5. 该项目是否具有 Tempest 覆盖率的 CI？如果是，请说明性质（API 和/或场景）。

    API 和场景。非投票权。

  • C6. 项目如何持续验证升级？项目是否需要或支持 Grenade 覆盖的 CI？

    没有持续的升级测试。

  • C7. 该项目是否提供多节点 CI？

    否。

发行足迹

  • R1. 该项目是否采用语义化版本控制 (semver)？

    是的。

稳定的回溯

  • S1. 该项目是否有稳定的分支和/或标签？请提供回溯历史记录。

    Liberty 和 Mitaka 可用。Backports 由 neutron 稳定团队控制。子项目遵循与 neutron 不同步的发布节奏，必须尽快纠正。

客户端库

  • L1. 如果该项目需要客户端库，它是如何实现 CLI 和 API 绑定的？

    是。尚未进行 OSC 过渡。

评分卡

评分卡

N0 | Y

N1 | N

N2 | 否

N3 | 是

N4 | 是

N5 | 否

D1 | 是

D2 | Y

D3 | 否

D4 | 是

C1 | 否

C2 | 是

C3 | Y

C4 | 否

C5 | Y

C6 | 否

C7 | 否

C8 | 是

R1 | 是

R2 | 是

R3 | 是

R4 | 是

S1 | 是

L1

N

总结：该子项目最近取得了很大的进展。仍然存在一些差距，例如 gate 队列中缺乏详尽的覆盖（当前的 tempest 测试是非投票权），以及与 master 对齐。客户端扩展最终需要重写。但是，该子项目似乎没有缺乏在需要时及时取得进展的资源和重点。