Neutron-Lib 分解

https://blueprints.launchpad.net/neutron/+spec/neutron-lib

本提案旨在稳定 Neutron 的子仓库（包括高级服务和分解的插件）中使用的某些通用接口。

问题描述

将功能和厂商代码从 neutron 中分离出来的一个目标是，提高核心 neutron 的关注度，使其稳定，并提高更改的速度。由于服务仓库和分解的插件/驱动程序都在导入和使用内部 neutron 接口，除非我们对所有这些代码运行现有测试，否则重构或进行简单的更改将变得困难，而不会破坏这些新分离的项目和插件。

此外，由于 openstack/requirements 规则关于全局依赖项，以及 neutron 不在列表上，因此 neutron 已安装存在一定的“魔法”依赖关系。我们最终不得不假设 neutron 存在，并且无法检查存在的版本是否兼容。

驱动此更改的需求是

  • 一组被认为是“稳定”的 neutron 方法，这些方法不会在没有长期弃用计划的情况下被删除或更改其方法签名。

  • 这不是一个机械式的分割。对于每个模块，我们必须确定当前接口是否是我们想要支持的接口，或者是否需要更改。并且对于每个模块，可能需要严格的接口测试。

  • 在“分割”过程结束时，没有 co-gate（联合门控）。

  • pypi 中的一个库。

  • 将此库添加到全局 requirements 列表中。

  • 在各种项目的 requirements.txt 中对库进行版本引用。

提议的变更

本提案是将 neutron 分解为可重用的库代码的 neutron-lib 和 neutron 核心（服务器、代理、插件、驱动程序）。创建 neutron-lib 的一部分将涉及为暴露的库方法创建严格的接口测试。

该库将位于新的仓库 neutron-lib 中，并将发布到 pypi。

这不是一个机械式的分割，而是每个移动到库中的代码片段都需要满足几个标准

  • 这是否是一个有意义的通用库中的可重用模块？

  • 它是否有接口测试，或者需要添加吗？

  • 当前的接口是否适合于一个库，或者是否需要重构？

一些简单的项目，例如 exceptions 模块，可以直接作为本蓝图的一部分移动，但是即使是不被任何人共享的简单代码也不应该移动。大多数具有任何复杂性的模块都需要单独的蓝图和仔细考虑。

当

  • 一个带有测试框架和 Jenkins 的 neutron-lib 仓库存在时，可以认为本蓝图已完成。

  • neutron-lib 的稳定版本已发布到 pypi。

  • Neutron、neutron-lbaas、neutron-fwaas、neutron-vpnaas 通过 requirements.txt 依赖于 neutron-lib，并且它们都不互相导入。

  • 上述四个仓库之间的 API 和功能测试完全分离。换句话说，没有 co-gate，并且接口破坏通过 neutron-lib 中的测试来强制执行。

  • 测试将不再在仓库之间共享代码。单元测试基类将是特定于仓库的，最初可能重复，并且会自行发展。基类需要的任何来自 neutron 的根功能都将成为包含在 neutron-lib 中或重构的候选对象。

参考资料