Ocata - Stadium 健康度

有关标准的详细信息，请查阅 Stadium 文档。

达到最低标准

Neutron 集成

Neutron 集成的最基本标准是采用 neutron-lib，并进行定期检查。今后，项目团队必须展示迁移到 neutron-lib 导入的 100% 的步骤。在构建网络组件时，架构和设计决策中不得存在任何红旗。需要在 neutron-lib 仓库中提供 API 定义和参考文档。

验收测试

检查 Grafana 仪表板是否正确显示定期作业，以及定期输出中的工件是否显示至少一次成功的运行。

评估

  • networking-bagpipe: 正常。

  • networking-odl: 正常。

  • networking-bgpvpn: 正常。

  • networking-midonet: 正常。

  • neutron-dynamic-routing: 正常。

  • neutron-fwaas: 正常。

  • networking-ovn: 正常。

  • networking-sfc: 正常。

文档

文档（开发者、部署者和最终用户所需）、发行说明和 API 参考（如果适用）。

验收测试

检查文档的有效链接。检查最新发行版（Newton）的发行说明的有效链接。检查 API 参考的有效链接。

评估

  • networking-bagpipe: 正常。

  • networking-odl: 正常。

  • networking-bgpvpn: 需要 API 文档。

  • networking-midonet: 需要 API 文档。

  • neutron-dynamic-routing: 需要 API 文档。

  • neutron-fwaas: 正常。

  • networking-ovn: 正常。

  • networking-sfc: 需要 API 文档。

持续集成

必须提供 Grafana 仪表板；单元（py2x 和 py3x）和 tempest（API 和场景）作业必须进行门控并稳定。这意味着跳过基本网络测试的正则表达式将不被容忍。对于具有数据库迁移的项目，必须提供同步测试。

验收测试

检查 Grafana 仪表板是否存在。检查单元测试是否通过。检查门控 tempest 测试。检查场景测试。检查数据库迁移测试。

评估

  • networking-bagpipe: 正常。

  • networking-odl: 正常。

  • networking-bgpvpn: 正常。

  • networking-midonet: 正常。

  • neutron-dynamic-routing: 需要场景测试。需要数据库/同步验证。

  • neutron-fwaas: 正常。

  • networking-ovn: 正常。

  • networking-sfc: 正常。

发行足迹

Semver、上限约束和机器人提案集成是必须的。发布 tarball 和发行说明必须在 releases.openstack.org 上可用。对于每个受支持的发行版，应该至少有一个已发布的交付成果。

验收测试

查找在 releases.openstack.org 上可用的 tarball 和发行说明链接。检查版本。检查需求仓库中的项目是否存在。检查是否使用上限约束。

评估

  • networking-bagpipe: 正常。

  • networking-odl: 正常。

  • networking-bgpvpn: 正常。

  • networking-midonet: 正常。

  • neutron-dynamic-routing: 正常。

  • neutron-fwaas: 正常。

  • networking-ovn: 正常。

  • networking-sfc: 正常。

稳定的回溯

与 neutron 分支对齐的稳定分支是必须的。

验收测试

检查支持的稳定分支（mitaka 和 newton）。检查 tox_install.sh 是否固定到正确的分支。

评估

  • networking-bagpipe: 正常。

  • networking-odl: 正常。

  • networking-bgpvpn: 正常。

  • networking-midonet: 正常。

  • neutron-dynamic-routing: 正常。

  • neutron-fwaas: 正常。

  • networking-ovn: 正常。

  • networking-sfc: 正常。

客户端库

对于需要客户端扩展的项目，必须存在 OSC 绑定。

验收测试

检查 python-neutronclient 中是否存在 OSC 绑定。

评估

  • networking-bagpipe: 不适用。

  • networking-odl: 不适用。

  • networking-bgpvpn: 需要移植到 python-neutronclient。

  • networking-midonet: 需要移植到 python-neutronclient。

  • neutron-dynamic-routing: 需要移植到 python-neutronclient。

  • neutron-fwaas: 正常。

  • networking-ovn: 不适用。

  • networking-sfc: 需要移植到 python-neutronclient。

总结

项目

集成

文档

持续集成 (CI)

发布

维护

CLI

networking-bagpipe

已满足

已满足

已满足

已满足

已满足

N/A

networking-odl

已满足

已满足

已满足

已满足

已满足

N/A

networking-bgpvpn

已满足

需要改进

已满足

已满足

已满足

需要改进

networking-midonet

已满足

需要改进

已满足

已满足

已满足

需要改进

neutron-dynamic-routing

已满足

需要改进

需要改进

已满足

已满足

需要改进

neutron-fwaas

已满足

已满足

已满足

已满足

已满足

已满足

networking-ovn

已满足

已满足

已满足

已满足

已满足

N/A

networking-sfc

已满足

需要改进

已满足

已满足

已满足

需要改进

neutron-vpnaas (*)

已满足

需要改进

需要改进

已满足

需要改进

需要改进

networking-l2gw (*)

需要改进

需要改进

需要改进

需要改进

需要改进

需要改进

networking-calico (*)

需要改进

需要改进

需要改进

需要改进

需要改进

N/A

networking-onos (*)

需要改进

需要改进

需要改进

需要改进

需要改进

N/A

(*) 要重新申请在 Pike 或未来版本中的包含资格。

仪表盘

如何协调 API 和客户端绑定

Stadium 演进工作的一个关键步骤是将 API 定义/文档和客户端绑定整合到 neutron-lib 和 python-neutronclient 中。如果满足所有标准，并且未解决的标准是文档和 CLI，那么很明显，为了端到端地完成工作并使项目保持在 neutron 治理中，项目团队需要贡献 API 定义、其 API 参考文档和客户端绑定到 neutron-lib 和 python-neutronclient 中。

为了解决这个需求，请按照以下步骤操作

  • 提出一个包含 API 定义和 API 文档的 neutron-lib 补丁。使用主题 ‘stadium-implosion’。您可以将 API 定义和 API 参考分解为单独的补丁，但这会延长合并过程。如果您将其分解，请对这两个补丁使用相同的主题。

  • 提出一个包含 OSC 命令、CLI 文档以及 API 绑定的 python-neutronclient 补丁。使用上述提示的主题 ‘stadium-implosion’。使客户端补丁依赖于 neutron-lib 补丁，反之则不行。这是因为，如果 API 补丁因任何原因崩溃，我们不需要在客户端发布之前回滚客户端补丁。

一旦所有未解决的 ‘stadium-implosion’ 补丁合并，将要剪切 neutron-lib 和 python-neutronclient 的新版本。此时，当 Bot Proposal 更改合并时，API 定义就可以在子项目中使用了，这标志着 Ocata 的 Stadium 工作完成。

注意：这些补丁的合并取决于确认已解决所有未解决的工作，但审查仍将继续进行。