Neutron Stadium 进化¶
本规范的目标是三方面的
定义什么是 Neutron Stadium。
定义 OpenStack 中网络社区的含义。
定义如何随着时间的推移维护 Stadium 的指南。
问题描述¶
Neutron 发展成为一个庞大的单体代码库，其核心团队在许多方面都面临着进展困难，例如添加新功能、确保稳定性等。在 Kilo 时间框架内，一项分解 工作 启动，代码库被分解为独立的努力，例如高级服务以及 L2 和 L3 服务的各种第三方解决方案。
该举措的结果好坏参半，但为由此产生的各个独立团队提供了更快迭代和缩短功能上市时间的良机。这归功于增加的自主权和隐式信任模型，使得对 PTL 和 Neutron 驱动程序/核心团队缺乏监督在少数举措中是可以接受的。然而，提出的 安排 使项目能够根据描述和隶属意愿 自动 列入 Neutron 项目。随着不断增加的纳入数量，PTL/驱动程序团队确保 API、架构、设计、实现和项目测试的一致性，以及文档、项目间通信、发布管理、稳定反向移植等各个方面的质量，变得越来越困难。统一 API 的问题尤为重要，因为 Neutron 平台非常灵活，以至于项目可以在功能暴露方式上采取完全不同的方向，使得 PTL 和驱动程序团队难以确保遵循良好的 API 设计原则。在每个项目独立的情况下，这可能可以接受，但允许在 Neutron 框架下独立 API 演进是适得其反的。
简而言之，当前的自主权让步和力求一致性的安排显然具有挑战性，因为存在两种相互冲突的力量。必须在一种既能让 Neutron 开发继续保持其敏捷开发轨迹，又不损害一致性，并且不使 PTL 和 Neutron 团队成为项目日常管理中的瓶颈的方式下取得更好的平衡。
提议的变更¶
Neutron Stadium 是以下文档中列出的项目
https://governance.openstack.org/tc/reference/projects/neutron.html
该列表包括 Neutron PTL 和核心团队直接参与并日常管理的项目。为此，PTL 和团队确保在 Stadium 中遵循共同的实践和指南，涵盖软件开发的所有方面，从概念到编码、测试、文档等等。
Stadium 并非旨在成为 OpenStack 网络项目的 VIP 俱乐部，也不是 OpenStack 中的一个高级别。它仅仅是 Neutron 团队和 PTL 在整个发布 周期 中制作 Neutron 产品时负责的项目列表。
本规范提出了如何修改当前列表（截至 2016 年 5 月），以维护 Stadium 的完整性，以及如何在需要修改列表时确保这种完整性得到维护。
项目何时属于 Stadium？¶
为了被认为是 Stadium 的一部分，项目必须展示出与 Neutron 核心项目保持一致的记录。这意味着展示出采用 Neutron 核心团队主导的实践的证据。其中一些实践通常已经被最成熟的 OpenStack 项目遵循，不应被视为特别严格
详尽的文档：预计每个项目都将拥有开发者、用户/操作员和 API 指南，可从 docs.o.o 访问；
详尽的 OpenStack CI 覆盖率（单元、功能、tempest），使用 OpenStack CI（上游）资源（这意味着使用 infra CI，而不仅仅是下游 CI，因为需要 Grafana 支持）；团队可以访问 CI 资源和历史数据是确保项目稳定性和健壮性的关键；
良好的发布足迹，根据所选的发布模型；
遵守弃用和稳定反向移植策略；
采用 neutron-lib（应用相关的黑客规则），并证明与 Neutron 核心内部的良好解耦；对 neutron-lib 更改执行单元测试也有利于展示项目的稳定性；
根据 OSC 过渡 计划 开发客户端绑定和 CLI（在适用时）。这意味着 Neutron Stadium 项目的客户端将在 python-neutronclient 中托管。问题在于，一些服务扩展不会在 pypi 上发布（例如 fw、vpn 或 lb），因此很难在需要使用它们时获取客户端扩展。SFC 和 L2GW，例如，会在 pypi 上发布，因此对于它们来说问题不大。从理论上讲，它们的客户端扩展可以保留在它们自己的树中，但这会使与 OSC 插件模型的对齐更加困难。由于建议将扩展保留在 python-neutronclient 树中，因此采用一致的方法，将所有 Stadium 客户端扩展都放在 python-neutronclient 树中，以避免处理规则异常时产生混淆是有益的；
采用 neutron-api：任何 API 更改的提交必须遵循 Neutron RFE 提交流程，可能需要规范提交到 neutron-specs；
采用模块化接口来提供网络服务：这意味着 L2/7 服务以 ML2 mech 驱动程序和各自的服务插件的形式提供。服务插件可以暴露驱动程序接口以支持多种后端技术，并根据需要采用 flavor 框架。
最后两个标准对于以下原因尤为重要
为 Neutron 用户/操作员提供一致的 API 体验，并更密切地协助 Neutron 开发者。只有当 API 提案和更改通过单一举措进行引导时才能实现这一点。
提供可组合的网络解决方案：ML2/Service 插件框架早在几个周期前就被引入，旨在为用户提供选择的自由。多年来，许多解决方案已切换到使用 ML2/Service 插件来实现高级服务。尽管一些插件仍然使用核心插件接口来提供端到端解决方案，但强制采用 ML2 和服务插件作为 Neutron Stadium 项目的标准并不会使单体解决方案过时。它仅仅反映了 Neutron 团队对可组合性作为开放网络解决方案承诺之一的支持。在代码审查期间，Neutron 团队将继续确保更改和设计影响不会对树外代码产生负面影响，无论它是否是 Stadium 项目的一部分。
当一个项目被认为属于 Stadium 时，通常需要至少在两个 OpenStack 版本中证明符合上述实践的证据。申请纳入的考虑仅在每个 OpenStack 周期中的第一个里程碑内进行，此时 PTL 和 Neutron 团队进行发布计划，并有最多的时间来讨论治理问题。
Stadium 中的项目通常在第一个里程碑中整理自己的事务，在此期间会进行重新评估；一旦移除，项目不能在被驱逐的同一发布周期内重新申请。
如果一个项目无法被认为是 Stadium 的一部分怎么办？¶
上述标准意味着，除非满足所有标准，否则 Neutron PTL 无法对项目纳入给予肯定考虑。反过来，这要求新的举措从一开始就作为在 openstack.org 命名空间中托管的独立项目启动，如 创建者指南 所述。此外，纯粹通过其 REST API 与 Neutron 交互的项目也应被鼓励寻求其他形式的治理，例如申请成为顶级 OpenStack 项目并遵循 OpenStack 治理 中概述的新项目要求，而不是寻求 Stadium 纳入。利用专有软件和/或硬件的驱动程序也不会被考虑纳入 Neutron Stadium，因为无法访问该技术进行开发/测试和 CI 集成，以及 Neutron 团队无法在软件开发的任何方面提供有效反馈：从代码到基础设施和测试。这并不意味着 Neutron 团队将停止与支持这些举措的各个团队合作（正如过去的经验表明），事实上，鼓励任何团队寻求合作以解决与 Neutron 核心平台的集成问题。Stadium 之外项目的团队完全负责处理其解决方案的端到端 SDLC，从而获得授权。集成代码到外部系统仍然可以托管在 openstack.org 上，无论其性质如何，并可以访问任何其他 OpenStack 项目使用的相同资源。值得注意的是，它们可能没有必要寻求在 governance.openstack.org 上获得“认可”，因为它们通常位于 TC 考虑纳入的一层之下。此外，诸如市场驱动程序认证计划之类的其他程序是反映特定驱动程序解决方案质量水平的更有效工具，因为它们还会跟踪跨各种 OpenStack 版本的可支持性水平。
如果 Neutron Stadium 中的项目决定包含专有系统的驱动程序怎么办？¶
如今，一些 Neutron 项目仍然托管专有系统的驱动程序，例如 vpnaas、fwaas 和 lbaas/octavia；即使接受新驱动程序的决定在于各自的团队，但强烈建议这些成为例外而不是常态。如果其中一些努力在长期内不再是 Neutron 团队的责任，那么这一点就变得不太重要了。
我们如何构建一个网络社区？¶
自成立以来，Neutron 一直是 OpenStack 中的网络项目。它一直是提出和商定 API 和网络抽象的地方。与其他项目一样，也存在僵局和停滞。解决这些僵局的一种方法是允许各个举措进行隔离实验：最终代码胜出。即使这似乎还可以，Neutron 仍然缺乏将所有这些举措重新组合成连贯形式的能力。
为了解决这个问题，Neutron 团队应考虑采用 neutron-api 举措，以整合 API 提案。neutron-api 项目可以成为 Stadium 项目使用的组件，并可以作为 neutron api 代码库（例如 neutron/api、neutron/extensions 以及被认为适合 Stadium 纳入的任何其他项目（例如 bgp、l2gw、sfc 等））的衍生项目启动。对该模块的贡献将遵循 Neutron RFE 流程，如果需要，将规范提交到 neutron-specs。生成的代码最终将位于 api 模块本身中，而规范将托管在 neutron-specs 上。Stadium 中属于核心团队的每个项目都将在 neutron-specs 上拥有 +2 权限。neutron 驱动程序将继续拥有两个存储库上的 +W 权限。值得注意的是，各个核心团队的成员将定期被考虑加入驱动程序团队。参与 RFE 提交审查的水平、与 Neutron 代码库的经验以及对项目的承诺是确定该团队成员时考虑的因素。从实施的角度来看，api 模块可以独立存在，作为 Stadium 列表中的另一个存储库，或者作为 neutron-lib 下的 /api 模块合并。虽然前者方法允许对发布模型进行更精细的控制，但后者具有最大限度地减少最终端到端代码更改复杂性的显而易见的好处。
努力存在的原因以及需要通过 neutron-specs 进行 API 提案的要求有两个：a) 确保所有来自 Neutron Stadium 项目的 API 之间保持持续一致；b) 为 OpenStack 网络社区提供一个讨论和达成网络抽象共识的地方；c) 作为构建可互操作 API 的可靠基础。
当前 Neutron Stadium 项目列表会发生什么？¶
在撰写本文时，Stadium 包含以下项目。基于所有上述考虑，所有个人团队都必须在 Newton 时间框架内努力使当前提案成为现实。更具体地说，要被考虑纳入（继续成为 Stadium 列表的一部分），必须制定以下计划
neutron：核心团队必须启动 neutron-api，并将 api 模型/定义从 neutron 存储库中迁移出来。根据本提案中概述的指南，Neutron Stadium 上的开发者文档将被修改。
neutron-fwaas：fwaas 核心团队必须
完成过渡到 fwaas v2；
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
neutron-lbaas：由于 Octavia 的存在，该项目的存在现在受到质疑。这在 spinout 规范中进行了详细说明。简而言之，该项目将逐步淘汰，以支持 Octavia 成为一个顶级 OpenStack 项目。
neutron-vpnaas: 该项目在最近几个周期内的进展最少。测试和文档不足，因此 vpnaas 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
切换到 OSC 插件；
neutron-dynamic-routing: 这是在 Mitaka 时间框架中实现的 BGP 代码的衍生项目。目前正在进行中。
networking-l2gw: 这需要
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
将客户端代码移动到 python-neutronclient 并切换到 OSC 插件；
networking-bagpipe: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
networking-bgpvpn: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
将客户端代码移动到 python-neutronclient 并切换到 OSC 插件；
networking-calico: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
networking-midonet: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
将客户端代码移动到 python-neutronclient 并切换到 OSC 插件；
networking-odl: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
networking-ofagent: 该项目已被弃用并标记为删除。
networking-onos: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
networking-ovn: OVN 项目需要考虑切换回 ML2 驱动程序。这样做有以下好处
作为多超visor部署的解决方案：目前只有当一个超visor运行 Open vSwitch 时才成立。
在 OpenStack gate 中作为 ovs mech_driver 的可行替代方案：只有当我们进行同等替换时才能做到。
在同一个 Neutron 部署的上下文中实现裸机和虚拟配置；仅支持硬件 vtep 会限制许多利用第三方解决方案的潜在裸机场景。
获得 Neutron 团队针对 ML2 开发的许多性能/可靠性增强。
整个 L2-L7 堆栈中服务的可组合性。
networking-sfc: 核心团队将不得不
采用 neutron-api 和 neutron-lib；
完成文档、端到端测试，并展示升级能力；
将客户端代码移动到 python-neutronclient 并切换到 OSC 插件；
octavia: 这正在 neutron-lbaas 的上下文中解决。简而言之，最终将被视为顶级 OpenStack 项目。
python-neutron-pd-driver: 这是一个依赖于 Neutron IPv6 支持的项目，并引入了另一个前缀委托驱动程序，除了树中已有的那个。随着树中 dibbler 的实现，这不再那么必要了。如果在 O-1 中没有人采用它，放弃它是一个可接受的结果。
将这些单个项目的相应 API 扩展贡献给 neutron-api 并不意味着从头开始审查 API，因为这些 API 已经有可用的解决方案。话虽如此，任何通过审查潜在识别出的修订都需要按照 RFE 提交流程进行跟进。这些项目及其各自的核心团队将有时间遵守，直到 Ocata Milestone-1，之后，如果不遵守，将被从 Neutron Stadium 中删除。总而言之，一个团队可以决定不采用上述计划，并在 Netwon 时间范围内要求被删除。
这个截止日期被认为是确定的，但会根据我们整合 API 和 neutron-lib 成熟到 neutron 项目有效使用的程度，以及一旦提供彻底的文档来帮助各方完成过渡，进行修订。
现有的 OpenStack 项目如何申请加入？¶
目前在 OpenStack 上托管了一些不属于 Neutron 治理列表的项目，例如 tap-as-a-service，并且将来可能会创建更多项目。这些举措应该考虑成为 Neutron Stadium 的一部分，前提是参与团队之间已经建立了互惠互利的合作关系。如上所述，Stadium 不是精英俱乐部，而只是 PTL 和 Neutron 团队负责的项目。随着时间的推移，更多的参与和互惠互利的合作，Stadium 的加入就更像是一种形式。
文档、测试和升级策略都处于良好的状态，如前所述；
客户端扩展作为 OSC 插件可用；
采用 neutron-lib；
然后需要提交申请请求，并附带 RFE 和后续规范提交，其中提供以下信息
指向用户和开发人员文档的链接；
指向服务器和客户端内部结构的链接；
指向 CI 作业（例如单元测试、tempest、grenade 等）以及 Grafana 仪表板的链接；
指向稳定的回溯和发布交付物的链接；
指向 API 规范和定义的链接；
一旦通过 RFE 流程评估并成功批准，团队将共同努力将 API 和客户端组件分别迁移到 api 模块和 python-neutronclient 仓库。新添加的项目承诺从那时起采用 Neutron RFE 提交流程进行 API 更改（仅限 API 更改），并向 neutron-specs 提交规范（如果需要）。
为什么这种 Stadium 安排有益？¶
Stadium 为志同道合的人们提供了一个协作、创新和迭代网络解决方案的地方，并提供了一定程度的保证，即属于 Stadium 的项目与其他 Stadium 项目的行为类似，从而为 Neutron 团队带来更可持续的维护工作。另一方面，Neutron 团队负责 Stadium 项目的交付成果（文档、发布说明等），因此为下游用户提供更高的可见性。Neutron Stadium 项目的贡献者参与 Neutron PTL 选举过程，并与其他 OpenStack Active Technical Contributor 具有相同的地位。
这个提案有什么缺点？¶
清理 Stadium 并使其保持正常运行的成本不可忽略，尽管标准旨在轻量级，并且在 Stadium 启动并运行后对团队施加的负担最小。这是保持所有网络相关工作协同工作的权衡。希望现在已经清楚，将负面含义与不属于 Stadium 的项目联系起来仅仅是一种误解：一些项目确实可以申请成为 OpenStack 的顶级项目，而另一些项目则更适合作为独立的举措。
是否有其他值得考虑的替代方案？¶
欢迎提出建议。
