跳转到： 导航, 搜索

Network/Incubator

注意 - 这目前是一个正在讨论中的提案，并非 Neutron 开发过程中的正式组成部分。

是什么？

neutron-incubator 是 Neutron 核心团队拥有和管理的拟议的新 git 仓库，用于在开发过程中提供对 API 扩展的访问。该仓库将促进快速迭代，同时遵循 OpenStack 的审查流程、测试和社区流程。

使命

为了在社区内提供一个明确的位置，用于在采用到集成发布之前成熟的 Neutron API 扩展。

为什么需要独立的仓库？

集成发布预计是稳定的，并且团队需要为一年以上提供支持。这些要求给核心团队带来了很大的压力，因为由于发布仅每半年进行一次，API 必须绝对完美。从 Grizzly 周期开始，团队尝试了各种不同的工作流程来提高开发质量并减少长期技术债务。这些工作流程实际上增加了提案人和核心团队的负担，因为它们需要一系列完全可用的补丁。独立的仓库将允许扩展以对开发人员和审查人员而言合理的方式成熟。

发布流程

neutron-incubator 项目将不参与集成发布流程。发布将随着功能或重大更改的合并而发生。发布的 Alpha 库将发布到 PyPI，以便操作员轻松使用。OpenStack Infra 提供了工具，可以轻松发布新的更新。标记/发布的能力将为孵化器提供发布正在开发中的新版本 API 的方式。

仓库规范

  • 仓库将是可作为测试伴侣库安装的 API 扩展的集合。
  • 接受孵化的 API 应该在 2 个周期内实现毕业。（注意：如果某个功能需要更长时间，则该功能过于不成熟，不符合孵化器的资格，应在 StackForge 中迭代，然后稍后重新申请。）
  • 扩展将像任何其他 Neutron 扩展一样加载。
  • 孵化器最初将遵循 OpenStack 规则，在合并之前由核心成员提供两个 +2 批准。此要求是为了确保毕业审查不是核心团队首次检查代码的时候。
  • 所有拟议的更改必须通过与主服务器项目相同的 HACKING 规则。
  • 所有更改必须通过单元测试
  • 所有更改必须通过功能测试
  • 所有更改不得破坏 Neutron 的功能和单元测试
  • 所有更改不得破坏 Neutron 的 tempest 测试
  • 子团队可以请求 PTL 或其他指定人员在关键功能合并后将更新的 alpha 库发布到 PyPI，以协助测试和反馈。
  • Neutron 项目内部的功能可能不依赖于孵化代码
  • API 更改在合并时不需要可用的实现。（注意：实现必须有效才能毕业）
  • 应与 N 和 N-1 版本兼容（使操作员能够针对稳定版本进行测试）
  • 任何数据库迁移都应保持在单独的时间线中，并应小心避免破坏稳定的 N 到稳定的 N+1 升级

纳入提案

网络程序中的子团队可以通过 openstack-dev 邮件列表、每周 Neutron 团队会议或设计峰会会议提出新的扩展。如果核心团队认为拟议的扩展符合网络程序的使命，则 API 扩展将被添加到 neutron-incubator 仓库。

定期审查

孵化器中的所有扩展都应定期审查，以衡量和提供有关进度的反馈。

退出孵化

API 扩展或正在开发的功能可以通过毕业、剥离或废弃来退出孵化器。

毕业

当满足以下要求时，扩展将有资格毕业

  • 符合 网络程序范围
  • 成熟的 API 定义，没有主要的计划向后不兼容的更改
  • API 与当前的稳定 API 一致
  • 开源参考实现
  • 实现与 Neutron 架构一致
  • 完整的单元测试覆盖率
  • 完整的函数测试覆盖率
  • 开发者文档
  • 支持的测试/文档已准备好立即提案：（注意：链接到私有树中的提交是可以接受的）
    • 一组 Tempest 测试 (QA)
    • API 文档 (Docs)
    • 用户文档 (Docs)
    • 建议的 CLI 支持 (python-neutronclient)
    • Horizon UI 支持
    • OpenStack SDK 支持
  • 建议的并发合并工作规范
    • 关于如何使用开源组件大规模部署的规范或文档。
    • 数据库迁移工作的规范
  • 必须证明以下两者之一

树内可扩展选项和/或多厂商支持（驱动程序或通过兼容层）。注意：需要可扩展的开源实现选项。

  • 用于厂商驱动程序的稳定的第三方 CI。
  • 如果 API 替换了另一个扩展，则必须详细说明迁移计划，并通过 Grenade 测试进行测试。
如何毕业

子团队将向 openstack-dev 邮件列表发送请求。PTL 将安排在未来的每周会议上进行讨论。讨论将寻求验证是否满足了要求。

剥离

Neutron 团队可以选择将扩展剥离到单独的项目中（例如 git 仓库、bug 跟踪等）。剥离可能发生在

  • 扩展需要由具有特定领域知识的专用核心团队进行管理。
    • 扩展应该对部署者是可选的。
    • 网络程序可以请求 TC 允许该项目属于集成发布或集成发布之外的新项目。
  • 扩展的发展方向不符合网络程序的范围。（剥离到 StackForge）

废弃

如果 API 未能获得关注，开发人员支持减少或在负责的子团队的要求下，核心团队可以删除任何孵化组件。该过程将通过在 gerrit 中提出代码删除建议并向 openstack-dev 邮件列表发送通知来启动。在核心团队有时间考虑请求并提出任何疑虑之前，审查不得批准，直到 7 天后。

核心团队

Neutron 的当前核心团队最初将是孵化器的核心团队。将来，如果需要，团队可以决定添加仅用于孵化器的核心成员。

对 Neutron 的影响

将向 Neutron 添加一个额外的 CI 作业，以确保主服务器项目中的更改不会破坏孵化代码。

Juno/Kilo 孵化候选者

  • LBaaS v2
  • 基于组的策略
  • BGP 动态路由
  • VPNaaS (SSLVPN)
  • QoS
从 "https://wiki.openstack.org/w/index.php?title=Network/Incubator&oldid=61732" 检索