Open Stack

Hi Artem,

I will attempt to answer your questions below in-line.

Michael

On Wed, Feb 17, 2021 at 8:55 AM Artem Goncharov
<artem.goncharov at gmail.com> wrote:
>
> Hi all,
>
> In our cloud we have a non Octavia LoadBalancer provided by vendor with no possibility to get it replaced with real Octavia. I see there is possibility to provide drivers for Octavia to operate other types of load balancers (https://docs.openstack.org/octavia/latest/contributor/guides/providers.html), but there are still some issues/questions:
>
> - is it possible to make Octavia only expose it’s API and make the driver transpose calls into the internal LB

Octavia is designed to provide the load balancing API for OpenStack.
It provides a "provider driver" architecture that allows one or more
load balancer implementations to be behind the Octavia API. The
specification[1] for this provider driver API was developed in
collaboration with third party vendors (the spec was authored by a
vendor).

Currently there are a number of provider drivers available[2] for
Octavia for various load balancing appliance vendors. This is the list
we know of, there may be others. The OpenStack community directly
maintains three of these drivers that are based on open source load
balancing engines (amphora, amphorav2, and the OVN provider driver).

As you mentioned, we provide a "provider driver development guide"[3]
to help anyone interested in implementing a new provider driver to be
available via the Octavia API.

If you are running Octavia with only non-amphora provider drivers, you
only need to deploy the following Octavia components[4]: Octavia API,
Driver Agent, OpenStack Database, and Housekeeping. That said, most
deployments seem to leave the amphora driver available as an option in
addition to other provider drivers.

[1] https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html
[2] https://docs.openstack.org/octavia/latest/admin/providers/index.html
[3] https://docs.openstack.org/octavia/latest/contributor/guides/providers.html
[4] https://docs.openstack.org/octavia/latest/reference/introduction.html#a-10-000-foot-overview-of-octavia-components

> - there is no need for any data persistency on the Octavia side, since there are other interfaces to operate LB what will cause inconsistencies otherwise

I think what you are asking here is "why do we need to store anything
in the OpenStack database when using a provider driver?". Here are a
couple of reasons the design went this way:
1. API data consistency. By maintaining the Octavia schema in the
OpenStack database we can assure that the Octavia API returns
consistent values no matter what driver implements the load balancing
engine. We also encourage providers to not directly access the Octavia
schema in the OpenStack database. It can change at any time. We
provide interfaces for the providers to use if they need to access
data maintained by Octavia.
2. A number of our APIs can return a large number of records,
including recordsets that have results from multiple provider drivers.
It would provide a poor user experience if we needed to round trip to
the provider driver and likely an appliance for each record returned
in these result sets.
3. We also need to be able to provide hooks for integration into other
OpenStack services for certain events that may be reported from the
provider driver. For example, we provide integration into alternate
statistics/metrics systems via our statistics drivers. We give the
provider drivers more flexibility by allowing them to push those
statistics than having the Octavia processes poll them.

> - can the driver have access to the API user data (user sends X-Auth-Token, it gets validated by keystonemiddleware, but I need to pass extra info to the underlaying internal LB API). Here I do not need anything special, it is more or less get access to the used token to pass it further. Ideally auth can be offloaded completely to the underlaying LB

No. The provider driver development guide lists the tenant information
that is provided to the provider drivers.
This again was an intentional design choice.

As an OpenStack service, we need our API to integrate with the
OpenStack ecosystem. This includes working with Keystone, other
services, and validating a consistent Role Based Access Control policy
set. Having an Octavia provider driver handle user authentication and
authorization is inconsistent with the OpenStack API goals. Obviously
a third party system can be integrated with Keystone, but doing so
from an OpenStack service other than Keystone is not currently
supported by Octavia.

That said, you can run the Octavia API without Keystone (NoAuth mode),
but this is not something that is not tested or currently a focus of
the Octavia team.

We do provide information about the project requesting a resource via
the provider driver API. It is a best practice that if a provider
driver/load balancer engine needs to interact with other OpenStack
services (nova/neutron/etc.) that the provider establishes the
required access and RBAC roles directly with those services and not
rely on impersonating the user by re-using their API token. Re-using
their token is fragile given tokens have a fixed lifetime and you do
know know how much lifetime is remaining when the user makes the
initial API request. It could expire before your driver is able to
reuse it. This also raises API auditing issues, etc.

> This all sounds like writing simple API convertor, but we really want service behaviour is 100% compatible to Octavia to avoid further issues (and perhaps convincing Octavia can replace other solution). Is this achievable? If yes I would really appreciate technical hints how this can be implemented.
>
> I feel like Octavia is already covering such use case (or at least intend to do so), but I am lost in docs.

Yes, Octavia is set up to enable additional/alternate load balancing
engines. If there are requirements beyond what we have today, Octavia
is a living open source community, so enhancement proposals and
patches are always welcome should the existing work not meet your
needs.

The "Provider Driver Development Guide" should be the starting place
for developing a new Octavia provider. The provider driver interface
stub[5] is provided in octavia-lib (our library for provider drivers).
If you have questions about it, the Octavia team is available in the
#openstack-lbaas IRC channel and via this mailing list.

[5] https://github.com/openstack/octavia-lib/blob/master/octavia_lib/api/drivers/provider_base.py