移除 neutron-LBaaS，又名 LBaaS 项目拆分¶

Octavia 项目在创建新的 LBaaS 参考实现的同时，也以标准的 pecan/wsgi OpenStack 端点实现了 LBaaS API。

Octavia LBaaS API 将与 Neutron LBaaS v2 API 完全相同且兼容，除了缺少 /lbaas 根 URL token。

现有 neutron API 端点的用户在两个周期内不会看到任何差异，这意味着可能在 P 或 Q 版本中移除，具体取决于这项工作何时完成。请注意，如果 shim 维护成本足够低，它可能会存在更长时间；这取决于 neutron PTL 和核心团队的决定。

本规范描述了移除 LBaaS 作为 neutron 扩展，并使其成为一个独立项目的过程。

问题描述¶

Octavia 提供了一个与 neutron-lbaas 提供的 API 和插件机制几乎完全相同的 API 和插件机制，而无需紧密耦合，这引发了我们现在为什么要维护两者的疑问，现在 lbaasv1 已经过时。本次拆分的的主要目标是简化两者的管理和实现，同时为操作员和最终用户提供尽可能无缝的体验。

拆分 LBaaS 项目的原因有很多

将您的服务塞进 neutron-server 的内部，而您的代码却在单独的仓库中，这一直是一个相当脆弱的方案。
- 核心 neutron 的重构可能会破坏 LBaaS。
- 共同 gate 会增加两个项目的 gate 不稳定性，并且可以移除。
- Neutron 扩展会妨碍微版本管理，并使迁移变得混乱。
我们将不再重复测试几乎相同的功能，并且消耗更多的基础设施和测试资源。
LBaaS 和 neutron 的活跃团队几乎没有重叠，因此管理两者的额外开销对 neutron 没有好处，并且会减慢 LBaaS 的速度。
Octavia 有自己的 REST API，所以为什么还要维护两个，如果我们可以使它们兼容呢？

反对的理由

此更改列表将分为“第一阶段”和“第二阶段”。第一阶段是进行治理变更和停止维护 neutron-lbaas 的最低限度的更改，而第二阶段是任何独立 OpenStack 项目所需的逻辑后续步骤。

Octavia 是一个 API 服务器、LBaaS 的服务 VM 框架，以及 LBaaS 的参考实现。目前仅支持以服务 VM 为中心的驱动程序

第一阶段

在 Octavia 中，需要添加一个接口，以便可以在 API 服务器后面使用非服务 VM 驱动程序（例如硬件设备或现有的 lbaas 驱动程序）。此驱动程序接口应直接接受当前的 neutron LBaaS v2 驱动程序，前提是这些驱动程序仅限于传递的对象和公共 lbaas 插件接口。当前的 neutron lbaasv2 驱动程序将被移动到 octavia 仓库中，但任何深入 neutron 内部的驱动程序很可能会破坏。所以，不要深入内部。
修改 neutron-LBaaS API 扩展，使其成为直接的代理传递到 octavia api 控制器。
通知供应商验证他们的驱动程序是否与 Octavia API 控制器兼容，并迁移他们的第三方 CI。
通知使用 LBaaS 的其他项目，特别是 Heat。
移除 neutron-LBaaS/neutron 共同 gate。
验证从用户和 API 角度的最低文档覆盖率。
申请从 neutron stadium 到 big tent 的治理变更。这包括将 neutron-lbaas 移动到 octavia 中，除非 neutron /lbaas 代理是 neutron 自身的 pecan 路由，然后 neutron-lbaas 可以简单地被移除/发送到 attic。

第二阶段

创建客户端库，和/或在 openstackclient/sdk 中直接支持。现有的 ‘openstack loadbalancer’ 会发生什么？它只是在几个版本中 neutron 的代理吗？从长远来看，它将是一个 OSC 插件。
创建/验证/移动已经为 neutron-lbaas 编写的 API/安装指南/用户文档。

在此过渡期间，以及此之后一段时间内，neutron /lbaas 代理将使这对于用户来说是透明的。