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@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/enabl... [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-0...
- 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...