5.8 KiB
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
makse 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:
git://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.