<div dir="auto"><div>Thanks a look Michael.<div dir="auto"><br></div><div dir="auto">As I wrote persistency in Octavia DB will cause an inconsistencies due to presence and of other parallel API interface for modification, but ok.</div><div dir="auto"><br></div><div dir="auto">I know the issues with impersonalization, but I really want to avoid establishing trusts. Currently I am talkng about LB that is integrated with Keystone itself (old fork of NeutronLBaaS with multiple incompatible changes), and sadly I do not have possibility to alter anything there, so the only this I can do is really map Octavia API into this LB API. I can verify roles on Octavia side and do other housekeeping, but I can only reuse passed token.</div><div dir="auto"><br></div><div dir="auto">Anyway thanks a lot, will dig deeper into the code to clarify possibilities.</div><div dir="auto"><br></div><div dir="auto">Artem</div><div dir="auto"><br><div dir="auto"><div data-smartmail="gmail_signature" dir="auto">----<br>typed from mobile, auto-correct typos assumed<br>----</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Feb 2021, 20:40 Michael Johnson, <<a href="mailto:johnsomor@gmail.com">johnsomor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Artem,<br>
<br>
I will attempt to answer your questions below in-line.<br>
<br>
Michael<br>
<br>
On Wed, Feb 17, 2021 at 8:55 AM Artem Goncharov<br>
<<a href="mailto:artem.goncharov@gmail.com" target="_blank" rel="noreferrer">artem.goncharov@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> 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 (<a href="https://docs.openstack.org/octavia/latest/contributor/guides/providers.html" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/contributor/guides/providers.html</a>), but there are still some issues/questions:<br>
><br>
> - is it possible to make Octavia only expose it’s API and make the driver transpose calls into the internal LB<br>
<br>
Octavia is designed to provide the load balancing API for OpenStack.<br>
It provides a "provider driver" architecture that allows one or more<br>
load balancer implementations to be behind the Octavia API. The<br>
specification[1] for this provider driver API was developed in<br>
collaboration with third party vendors (the spec was authored by a<br>
vendor).<br>
<br>
Currently there are a number of provider drivers available[2] for<br>
Octavia for various load balancing appliance vendors. This is the list<br>
we know of, there may be others. The OpenStack community directly<br>
maintains three of these drivers that are based on open source load<br>
balancing engines (amphora, amphorav2, and the OVN provider driver).<br>
<br>
As you mentioned, we provide a "provider driver development guide"[3]<br>
to help anyone interested in implementing a new provider driver to be<br>
available via the Octavia API.<br>
<br>
If you are running Octavia with only non-amphora provider drivers, you<br>
only need to deploy the following Octavia components[4]: Octavia API,<br>
Driver Agent, OpenStack Database, and Housekeeping. That said, most<br>
deployments seem to leave the amphora driver available as an option in<br>
addition to other provider drivers.<br>
<br>
[1] <a href="https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html</a><br>
[2] <a href="https://docs.openstack.org/octavia/latest/admin/providers/index.html" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/admin/providers/index.html</a><br>
[3] <a href="https://docs.openstack.org/octavia/latest/contributor/guides/providers.html" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/contributor/guides/providers.html</a><br>
[4] <a href="https://docs.openstack.org/octavia/latest/reference/introduction.html#a-10-000-foot-overview-of-octavia-components" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/reference/introduction.html#a-10-000-foot-overview-of-octavia-components</a><br>
<br>
> - 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<br>
<br>
I think what you are asking here is "why do we need to store anything<br>
in the OpenStack database when using a provider driver?". Here are a<br>
couple of reasons the design went this way:<br>
1. API data consistency. By maintaining the Octavia schema in the<br>
OpenStack database we can assure that the Octavia API returns<br>
consistent values no matter what driver implements the load balancing<br>
engine. We also encourage providers to not directly access the Octavia<br>
schema in the OpenStack database. It can change at any time. We<br>
provide interfaces for the providers to use if they need to access<br>
data maintained by Octavia.<br>
2. A number of our APIs can return a large number of records,<br>
including recordsets that have results from multiple provider drivers.<br>
It would provide a poor user experience if we needed to round trip to<br>
the provider driver and likely an appliance for each record returned<br>
in these result sets.<br>
3. We also need to be able to provide hooks for integration into other<br>
OpenStack services for certain events that may be reported from the<br>
provider driver. For example, we provide integration into alternate<br>
statistics/metrics systems via our statistics drivers. We give the<br>
provider drivers more flexibility by allowing them to push those<br>
statistics than having the Octavia processes poll them.<br>
<br>
> - 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<br>
<br>
No. The provider driver development guide lists the tenant information<br>
that is provided to the provider drivers.<br>
This again was an intentional design choice.<br>
<br>
As an OpenStack service, we need our API to integrate with the<br>
OpenStack ecosystem. This includes working with Keystone, other<br>
services, and validating a consistent Role Based Access Control policy<br>
set. Having an Octavia provider driver handle user authentication and<br>
authorization is inconsistent with the OpenStack API goals. Obviously<br>
a third party system can be integrated with Keystone, but doing so<br>
from an OpenStack service other than Keystone is not currently<br>
supported by Octavia.<br>
<br>
That said, you can run the Octavia API without Keystone (NoAuth mode),<br>
but this is not something that is not tested or currently a focus of<br>
the Octavia team.<br>
<br>
We do provide information about the project requesting a resource via<br>
the provider driver API. It is a best practice that if a provider<br>
driver/load balancer engine needs to interact with other OpenStack<br>
services (nova/neutron/etc.) that the provider establishes the<br>
required access and RBAC roles directly with those services and not<br>
rely on impersonating the user by re-using their API token. Re-using<br>
their token is fragile given tokens have a fixed lifetime and you do<br>
know know how much lifetime is remaining when the user makes the<br>
initial API request. It could expire before your driver is able to<br>
reuse it. This also raises API auditing issues, etc.<br>
<br>
> 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.<br>
><br>
> I feel like Octavia is already covering such use case (or at least intend to do so), but I am lost in docs.<br>
<br>
Yes, Octavia is set up to enable additional/alternate load balancing<br>
engines. If there are requirements beyond what we have today, Octavia<br>
is a living open source community, so enhancement proposals and<br>
patches are always welcome should the existing work not meet your<br>
needs.<br>
<br>
The "Provider Driver Development Guide" should be the starting place<br>
for developing a new Octavia provider. The provider driver interface<br>
stub[5] is provided in octavia-lib (our library for provider drivers).<br>
If you have questions about it, the Octavia team is available in the<br>
#openstack-lbaas IRC channel and via this mailing list.<br>
<br>
[5] <a href="https://github.com/openstack/octavia-lib/blob/master/octavia_lib/api/drivers/provider_base.py" rel="noreferrer noreferrer" target="_blank">https://github.com/openstack/octavia-lib/blob/master/octavia_lib/api/drivers/provider_base.py</a><br>
</blockquote></div></div></div>