The Octavia project has, as part of creating the new LBaaS reference implementation, also implemented the LBaaS API as a standard pecan/wsgi openstack endpoint.
The Octavia LBaaS API would be identical and compatible with the Neutron LBaaS v2 API, excepting the /lbaas root url token being missing.
End users of the existing neutron API endpoint will see no differences for two cycles, which means potential removal in P or Q, depending on when this work lands. Note that if the shim is low-maintenance enough, it may live for even longer; that will be at the discretion of the neutron PTL and core team.
This spec describes the process for removing LBaaS as a neutron extension, and making it a standalone project of its own.
Octavia provides a virtually identical API and plugin mechanism that neutron-lbaas provides without the tight coupling, which calls into question why we are maintaining both, now that lbaasv1 is past deprecation. The main goals of this spinout will be simplifying the administration and implementation of both, while providing as seamless an experience as possible to operators and end users.
There are several reasons for spinning out the LBaaS project:
The reasons against:
This list of changes will be split into “phase one” and “phase two”. Phase one is the minimum list of changes necessary for a governance change and to stop maintaining neutron-lbaas as it is today, and phase two are logical next steps needed for any standalone openstack project.
Octavia is an API server, a service VM framework for LBaaS, and the reference implementation for LBaaS. Currently only service VM centric drivers are supported
During this transition, and for sometime after, the neutron /lbaas proxy will make this transparent to users.
Spec that outlines specific changes needed in Octavia for this to happen:
Proposed neutron-lbaas proxy shim layer:
Brandon’s work on making an lbaasv2 driver layer directly in Octavia:
WIP governance patch, which will remain WIP until phase one is nearing completion:
Octavia’s ‘api_handler’ interface, which is similar to the current lbaasv2 driver interface (see 311586 for work to make this seamless with current drivers):