LBaaS 插件可以将 VIP 分配委托给驱动程序¶
https://bugs.launchpad.net/neutron/+bug/1463594
目前 neutron lbaas 插件会为 VIP 创建一个 neutron 端口，然后将该信息传递给驱动程序以继续创建负载均衡器。在某些情况下，驱动程序需要控制 VIP 的创建方式。 Octavia 的工作促使人们认识到需要此功能，以便支持来自不同提供商的部署。
问题描述¶
由于 neutron lbaas 插件创建 neutron 端口作为驱动程序使用的 VIP，因此需要执行更复杂的 VIP 分配或需要进一步延迟 VIP 分配流程的驱动程序将不得不进行一些不可行的变通方法才能使其正常工作。
从部署者的角度来看，一些例子是
假设一个使用 nova 单元的环境，并且 VIP 将是分配给 nova 实例的 IP。由于正在使用单元，这意味着 nova 调度器将决定应该从哪个段和子网分配 VIP。如果 neutron 端口在创建实例之前创建，那么分配 IP 的段和/或子网可能会与 nova 调度器发生冲突。单元和网络段在 RFE [1] 中进行了解释和讨论。
VIP 分配可能需要一些外部服务来执行实际分配或 VIP 的额外预配置，在这种情况下，它不能在 neutron lbaas 插件中创建，并且需要留给驱动程序来创建。
提议的变更¶
将在驱动程序接口中添加一个非抽象方法。 这样，现有驱动程序无需更改，除非他们希望利用此新功能。 在插件创建 VIP 的 neutron 端口之前，它将查询驱动程序并确定是否已实现该新方法。 如果已实现，驱动程序将调用该方法，并且不会为 VIP 创建 neutron 端口。 如果未实现，则将进行正常的端口创建和驱动程序调用。 采用这种方式不会将实现细节泄露给用户或部署者，因为它只是驱动程序实现者的决定。
这可能会导致一个小的潜在问题，如果驱动程序异步实现新方法。 该方法将不会返回任何有关 VIP 的信息，因为它可能尚未分配。 这可能需要一个线程在后台运行，检查分配情况，然后更新 neutron lbaas 数据库。最终用户不会在创建负载均衡器调用返回时立即看到 VIP 的 IP。 该字段的填充最终会被延迟，就像 nova 实例不会立即分配 IP 一样。
我认为这是对 API 行为的可接受更改，因为即使 IP 立即返回，它仍然不是可用的 IP，直到负载均衡器完成配置。
