Octavia Charm

Problem Description

At present our support for LBaaS makes use of the neutron-lbaas service_plugin and service_provider drivers. In the existing implementation the load balancer code, which is a part of the datapath, is run in namespaces directly on the neutron gateway units.

The neutron-lbaas and neutron-lbaas-dashboard projects are marked as deprecated as of the Queens OpenStack release cycle and has stopped receiving updates. They will be removed entirely at some point in the future.

Our usage of neutron-lbaas driver also gives a sub-optimal configuration for users in need of TLS.

Proposed Change

The neutron-lbaas projects have been replaced by octavia, octavia-dashboard, and python-octaviaclient.

octavia has a separate API endpoint and implements a superset of the LBaaS v2 API. For migration of existing users there is a lbaasv2-proxy service plugin which allows neutron API endpoint to forward LBaaS v2 API calls to the octavia endpoint in a migration period.

Contrary to the neutron-lbaas implementation, octavia runs the in-datapath load balancer code as instances in your cloud. This gives richer flexibility both in terms of freedom of choice of provider of the load balancer software itself and dynamic scaling of the service.

On the scaling side, most if not all, of the octavia services benefit from being scaled out proportional to the number of running load balancers and load balancer life cycle events. Thus it makes sense to co-locate the API, Worker, Health Manager and Housekeeping Manager daemons in the same charm unit, and scale by increasing the number of charm units deployed.

A reference implementation load balancer based on Ubuntu cloud images running HAProxy called amphorae is available.

Alternatives

As our current dependencies for providing LBaaS are deprecated and set to be removed at a future date there are no real alternatives to doing this work.

Implementation

Assignee(s)

Primary assignee:

fnordahl

Gerrit Topic

Use Gerrit topic “octavia-charm” for all patches related to this spec.

git-review -t octavia-charm

Work Items

  • Implement a new principal octavia charm which will deploy the octavia API, Worker, Health Manager and Housekeeping Manager daemons. The charm MUST have all the characteristics you expect from a OpenStack API charm such as TLS, HA, pause / resume actions, upgrades etc.

  • Make necessary changes to neutron charms for operation with octavia.

  • Make necessary changes to openstack-dashboard charm for replacing the neutron-lbaas-dashboard with the octavia-dashboard.

  • Implement support for storing TLS private key secrets in Vault either through relation to barbican or by utilizing the castellan library directly.

  • Implement support for doing post-deployment configuration and plumbing of the private administration network between octavia and the load balancer instances it deploys. This will be done by interacting with the neutron API and deploying the neutron-openvswitch subordinate with the charm. The neutron-openvswitch subordinate will automatically take care of creating necessary tunnels for access to the overlay network and we can subsequently create OpenvSwitch ports on the units where octavia services are deployed.

  • Provide documentation and/or any actions necessary for obtaining, provisioning or indeed building (if necessary) the amphorae load balancer software images.

  • Provide documentation and/or any actions necessary for migrating existing load balancer workloads to octavia.

Repositories

A new git repository will be required for the octavia charm:

https://git.openstack.org/openstack/charm-octavia

Documentation

The octavia charm should contain a README with instructions on deploying the charm.

Security

  • Serving TLS terminated traffic is a basic feature of a load balancer service. With that comes responsibility for secure handling and storage of sensitive information such as private keys.

    Best practices for handling and storing these keys will be implemented.

  • If we are to provide our user with a mechanism to build the amphorae images, it must be made clear that the responsibility of keeping the built image secure and up to date rests solemnly with our user.

  • The presence of a direct network tunnel between the octavia unit placed in the undercloud control plane and the load balancer instances in the overcloud is a construct we have not encountered previously. We must consider all aspects of this carefully with security and integrity in mind.

Testing

Code written or changed will be covered by unit tests; functional testing will be done using Zaza.

Dependencies

  • To be able to support deployment of octavia charm in LXD containers we depend on Juju implementation of charm controlled LXD profile updates specification.