中子服务拆分提案

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/neutron/+spec/services-split

本提案涉及将中子仓库拆分为四个仓库的技术方面,一个用于基础的 L2/L3 互联互通,另外三个分别用于 LBaaS、FWaaS 和 VPNaaS。 在本规范中,这些仓库将分别被称为“neutron”、“vpnaas”、“fwaas”和“lbaas”,直到为仓库选择项目名称为止。

本规范不涉及治理问题。 关于该问题,请参阅本文档末尾的邮件列表主题,或与网络项目 PTL 沟通。

问题描述

以下内容是 Mark McClain 发起的一封邮件主题的无耻抄袭

在过去的几个月里,网络项目成员一直在讨论改进我们项目管理的方法。 当 Quantum 项目最初启动时,我们设想了一个包含所有网络相关事物的综合服务。 这种愿景在早期阶段为我们提供了良好的服务,因为团队主要专注于构建第二层和第三层;然而,随着项目开始构建第四层到第七层时,我们遇到了增长挑战。 最初,我们认为开发将贯穿整个网络堆栈的所有层,但实际上,开发集中在第二层和第三层或第四层到第七层。 在最近几个周期中,我们还发现这些集中点具有不同的速度,而一个核心团队迫使一方匹配另一方,从而损害了被迫放慢速度的一方。

提议的变更

展望未来,我们希望将中子仓库划分为多个独立的仓库,由一个共同的网络 PTL 领导。 该项目的当前使命将保持不变。

  • 仓库将通过保留所有更改历史记录的 infra 脚本进行拆分。

  • 现有的 lbaas 代码将移动到 lbaas 仓库,并由该团队继续支持。

  • 现有的 fwaas 代码将移动到 fwaas 仓库,并由该团队继续支持。

  • 现有的 vpnaas 代码将移动到 vpnaas 仓库,并由该团队继续支持。

  • 与核心中子不同,在仍然尝试构建社区/临界质量的同时,供应商代码将保留在每个服务仓库中。

  • 服务仓库将包含中子作为依赖项。 在 L3 代理重构为不从防火墙类派生之前,这可能会在短期内反转。 包维护者必须在从 Icehouse/Juno 升级到 Kilo 时,将服务与中子一起安装。

  • 服务仓库将支持与中子相同的 tox 环境。

  • 服务程序的错误修复需要继续回溯到中子的稳定分支,持续几个版本。 回溯应保留 change-id 和提交消息。

  • 在 Kilo 中,API 客户端/CLI 将通过 neutronclient。 这并不排除创建独立的客户端/API,但这不是一个拆分要求。

  • 这只是关于拆分仓库。 本规范中的任何内容都不应被视为弃用任何当前正在交付的服务代码,即使它移动了仓库。

  • 第三方 CI 必须指向相关的仓库。

  • 在 Kilo 中,四个仓库将在 master 上协同工作,但不在任何其他版本/分支之间。

Kilo-1(将在 12 月 8 日的中子会议期间进行)

  • 在拆分之前,将为新的仓库和新的核心团队创建 infra/project-config 更改。

  • 拆分后,所有 WildcardaaS 代码和数据库模型都将位于其新的仓库中,并保留历史记录。

  • 拆分后,lbaas/fwaas/vpnaas 服务代码将不再位于中子仓库中,并删除不相关的历史记录(例外:扩展和 l3 代理,见下文)。

  • 扩展将保留在中子中,直到 post rest-refactor,以避免破坏 co-gate。

  • 服务仓库将继续使用 neutron.conf 中定义的数据库,但将拥有自己的表和 alembic 链。 不允许在迁移链之间存在外键;现有的外键关系应在 Kilo 重构/清理期间处理。

  • 服务仓库将使用自己的配置文件,位于 /etc/neutron 下。

  • 合并到现有的 ‘feature/lbaasv2’ 中子功能分支上的代码将作为拆分的一部分合并到 lbaas 仓库中。

  • 所有当前提交到中子的服务 Gerrit 审查都必须被放弃并重新提交到相关的服务仓库。 规范审查将保持不变,因为规范仓库没有更改。

  • 拆分后,所有项目的 tox 都将干净地通过,除了永远无法通过的 py3 环境。

Kilo-2

  • 第三方 CI 更新为新仓库的截止日期。

  • Post REST-refactor 后,扩展将移动到服务仓库。

  • 重构 L3 代理,使其不依赖于服务代码。 这项工作是当前 Kilo L3 重构的一部分。

Kilo-3

  • 不再有跨越 alembic 链的外键。

  • L3 代理重构完成,打破中子/服务之间的循环异常,针对 l3_agent。

  • API 测试进入每个服务仓库。

L 发布

  • 在任何地方,服务导入中子时,评估它是否恰当地将中子用作库,或者是否意味着中子 API 中缺少接口。

M 发布

  • 服务将拥有自己的 REST 端点、数据库、配置文件和 CLI/API 客户端。

数据模型影响

服务数据模型将被移动到服务仓库,并从中子中删除。

服务仓库将拥有自己的数据库迁移链。

通过从拆分时中子数据库的状态开始并剥离非服务相关的表来创建初始数据库迁移状态。

引用中子模型的外部键将继续存储中子对象的 uuid,但关联的 orm 引用将转换为查询中子数据库。 现有的外部键关联:防火墙,无。 LBaaS:VIP 模型引用端口。 VPN:VPNService 引用子网和路由器。

REST API 影响

REST API 在拆分前后将保持相同。

安全影响

无。

通知影响

无。

其他最终用户影响

无。

性能影响

无。

IPv6 影响

无。

其他部署者影响

新的服务项目将拥有自己的数据库表、迁移链和配置文件。 此外,到 Kilo 结束时,中子需要从仓库之外加载所有服务 API 扩展。

对于 Kilo,中子将假定服务仓库存在,并在 neutron.conf 文件中默认包含指向其 API 扩展的路径 (api_extensions_path)。

在升级场景中,REST 控制器将反弹,但活动服务(负载均衡器等)将保持活动状态。

开发人员影响

任何导入 neutron.services 的代码都必须导入新的项目模块。

补丁可能需要重新提交到正确的仓库。

社区影响

这将使专注于一个或多个高级服务的团队产生更大的影响并确保进展。

备选方案

  • 什么也不做,将所有内容保留在一个仓库中。 这是现状,是不可持续的。

  • 中子拆分为两个仓库,一个中子,一个高级服务。 这种方法的优点是更大的初始社区、更简单的拆分以及供新的高级服务在树内“孵化”的场所,而不是中子。 缺点与继续将服务保留在中子本身类似:缺乏重点、流行服务的优先级可能会覆盖不太流行或较新的服务,以及缺乏关注点分离。

  • 服务到 stackforge。 完全分离的治理,必须孵化。

  • 服务拆分并拥有自己的 REST 服务器端点。 更多的关注点分离,需要更多的工作。

  • 服务完全拥有自己的数据库。 强制更好的分离,但可能在没有单独的 REST 端点之前就过度了。

  • 修改 gerrit 以允许一个仓库中的不同核心团队。 这并不能鼓励关注点分离,而且 gerrit 今天不支持这一点。

  • 拆分仓库但继续使用中子数据库(拥有自己的表,拥有自己的链)

  • 服务仓库需要将中子用作库,并且应该对中子有一个依赖项。 但是,为了适应从 Icehouse/Juno 到 Kilo 的无缝升级,依赖关系可以在一个周期内反转

    • 对于 Kilo,中子将对每个服务仓库都有依赖项,以便自动安装服务与 Kilo 的中子一起安装。 此外,仅对于 Kilo,中子将有一个 hacking 规则来防止导入任何服务仓库,作为准备。

    • 对于 Kilo,为了防止循环依赖,服务可以假定已安装中子代码,并根据需要导入它。

    • 对于 L,依赖关系将从中子中删除,并且每个服务仓库将添加自己的中子依赖项。

实现

负责人

主要负责人

https://launchpad.net/~dougwig

LBaaS 指定人

https://launchpad.net/~dougwig

FWaaS 指定人

https://launchpad.net/~snaiksat

VPNaaS 指定人

https://launchpad.net/~pcm

其他贡献者

https://launchpad.net/~mestery

工作项

拆分的工作项

  • 识别每个仓库的文件。

  • 调整 oslo 毕业脚本以进行 git 拆分。

  • 合并 lbaasv2 功能分支。

  • 调整新仓库中的导入。

  • 为每个项目添加依赖项。

  • 添加 hacking 规则到中子,以防止服务导入,除了 L3 代理中的现有导入。

  • 验证或添加中子加载树外服务插件的能力。

  • 创建初始服务数据库迁移文件,确保所有文件都已应用。

  • 修复各种文件(例如 README)中对中子的引用

  • 最终确定项目名称

  • Infra 补丁以创建新的仓库/组

  • 获得干净通过的单元测试。

在进行拆分时隐含的工作项,但将在之后单独/之后发生

  • 在任何地方,服务导入中子时,评估它是否恰当地将中子用作库,或者是否意味着中子 API 中缺少接口。

  • 重构 L3 代理,使其不要深入研究服务。

  • API 测试进入每个服务仓库。

依赖项

  • Infra 创建单独的仓库。

  • REST 重构不要同时发生。 这需要在之前或之后发生。

测试

  • 单元测试将在仓库之间拆分,与代码拆分相匹配。

  • Tempest 测试最初将保持不变,因为服务端点在拆分前后将是相同的。 接触数据库和/或配置文件的设置步骤可能需要更新以反映新的位置。

  • 高级服务测试将从“集成 gate”中删除。 负载均衡和朋友将仅与中子 co-gate,不再与 nova、cinder 和其他 co-gate。

Tempest 测试

未更改,除非测试在拆分时位于中子中,则它们将移动。

功能测试

通过扩展名称空间加载扩展的测试将更新为新的路径。

API 测试

未更改,除非测试在拆分时位于中子中,则它们将移动。

文档影响

用户文档

引用 neutron.conf 和中子数据库的文档需要修改以反映新的配置文件和数据库。

开发人员文档

引用 neutron.conf 和中子数据库的文档需要修改以反映新的配置文件和数据库。

参考资料