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 theoctavia
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 withoctavia
.Make necessary changes to
openstack-dashboard
charm for replacing theneutron-lbaas-dashboard
with theoctavia-dashboard
.Implement support for storing TLS private key secrets in
Vault
either through relation tobarbican
or by utilizing thecastellan
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 theneutron
API and deploying theneutron-openvswitch
subordinate with the charm. Theneutron-openvswitch
subordinate will automatically take care of creating necessary tunnels for access to the overlay network and we can subsequently createOpenvSwitch
ports on the units whereoctavia
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 inLXD
containers we depend onJuju
implementation of charm controlledLXD
profile updates specification.