|tags:||lbaasv2, octavia, load balancing, neutron|
OpenStack-Ansible currently offers LBaaSv1, but it is deprecated in Liberty and it is scheduled to be removed in Newton. LBaaSv2 became stable in Liberty and it provides several improvements over LBaaSv1:
However, LBaaSv2 does have some limitations:
Although LBaaSv1 support exists in OpenStack-Ansible already, it is deprecated in Liberty and it is scheduled for removal in Newton. It also has a limitation of one listening port per load balancer, which limits a user’s ability to host an application on more than one port (think HTTP and HTTPS) on a single load balancer.
LBaaSv2 replaces LBaaSv1 and will be supported by OpenStack developers going forward.
There will be several changes needed to deploy LBaaSv2:
We could choose to stay with v1 through the Mitaka release, but then we might be forced to remove it for the Newton release in favor of v2.
The vast majority of the changes should take place in the neutron role. LBaaSv1 is currently enabled by adding a service_plugin entry, and the same could be done for LBaaSv2. When the LBaaSv2 service_plugin entry is present, the neutron role would ensure that octavia is running and ready to receive requests.
The upgrade impact depends on whether a deployer is currently using LBaaSv1.
If a deployer is already using LBaaSv1, they would need to carefully consider their migration path to v2 since both implementations cannot run concurrently. However, if a deployer is already using v1, they could upgrade to Liberty or Mitaka without making any adjustments to how they use load balancers. Upgrading to Newton would require changes since LBaaSv1 is expected to be removed in that release.
If a deployer is not using LBaaSv1 at this time, then they would simply be gaining functionality that they did not have previously when they upgrade to Liberty, Mitaka, or Newton.
There are no sigificant performance impacts within LBaaSv2, but it could allow deployers to deploy HTTPS websites on the same IP address as their HTTP site.
Octavia also integrates with the Anchor and Barbican projects. Anchor allows users to obtain certificates from a pre-configured certificate authority (CA) within their OpenStack environment and Barbican can be used to store private keys for SSL/TLS connections.
LBaaSv2 should scale better than LBaaSv1 since it runs within virtual machines rather than inside the neutron-agents container with multiple haproxy-agents.
If an end user is not currently using LBaaSv1, then they would be gaining a new feature that they could consume via an API. Horizon panels are planned for Mitaka.
If an end user is currently using LBaaSv1, they would lose load balancer functionality when LBaaSv2 is deployed until they configure their load balancers within the LBaaSv2 API. Deployers must work closely with end users to determine the best path forward.
If a deployer is not currently using LBaaSv1, they could easily enable LBaaSv2 by adding a service_plugin within their openstack_user_config.yml for LBaaSv2, just as they do for LBaaSv1 today.
If a deployer is currently using LBaaSv1, they could continue using it without interruption (until the Newton release). If they choose to move to LBaaSv2, they would need to coordinate the changes with their end users to avoid lengthy service interruptions.
The LBaaSv2 deployment would be part of the neutron deployment, much like the current deployment process for LBaaSv1. No additional roles or playbooks are required.
This spec does not depend on any other development work in OpenStack-Ansible.
See the details in the Proposed Changes section above.
Tempest testing exists for the LBaaSv2 API but tempest tests for the octavia API are still in progress.
Some topics are mentioned above in the Proposed Changes section. The following topics must be documented: