Open Stack

Thanks a look Michael.

As I wrote persistency in Octavia DB will cause an inconsistencies due to
presence and of other parallel API interface for modification, but ok.

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.

Anyway thanks a lot, will dig deeper into the code to clarify possibilities.

Artem

----
typed from mobile, auto-correct typos assumed
----

On Wed, 17 Feb 2021, 20:40 Michael Johnson, <johnsomor at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210217/96d7e647/attachment-0001.html>