When a non-keystone plugin is used together with an unversioned endpoint,
we give up on discovery before figuring out both major version and
the correct endpoint. This is because get_endpoint_data is called with
discover_versions=False, so discovery assumes we have all information
already. It may be an issue in discovery itself, but I'm afraid to
touch that code. Instead, if get_endpoint_data returns no API version
with discover_versions=False, try with discover_versions=True, which
matches what the identity plugins do.
Also increase the unit test coverage.
We expect endpoint_override, but these plugins won't necessary
have it, they have endpoint instead.
Co-Authored-By: Dmitry Tantsur <firstname.lastname@example.org>
It's possible in get_api_major_version that the endpoint in question is
not found at all. In that case, we are documented to return None, but
what we do instead is throw an exception trying to get data off of the
keystoneclient.session has been long deprecated in favor of
keystoneauth1.session. This change corrects entries in the
documentation to use the correct library's session.
The new 'none' auth plugin and the old 'admin_token' plugin
are subclasses of BaseAuthPluign, not BaseIdentityPlugin.
That means if someone does:
s = session.Session(noauth.NoAuth())
a = adapter.Adapter(s, endpoint_override='https://example.com')
to get an Adapter on an endpoint using the none plugin, then does
it will fail because the none plugin doesn't have those methods.
There is, however, nothing about those methods that necessarily needs
authentication. That is, they can work just fine in contexts without
a keystone token or without authentication of any sort.
Ironic/Bifrost is specifically a usecase here, as standalone Ironic
wants to use the 'none' plugin, but consuming the API still needs to
get microversion info from the given endpoint.
Add methods to BaseAuthPlugin that take less arguments since the ones
about finding services in catalogs make zero sense in none/admin_token
There's several references to BaseAuthPlugin, unfortunately the
docs for BaseAuthPlugin didn't lead to anywhere useful. Added
links to the implementations so developers know what to do next.
Particularly for allowing the CLI to store and reuse previous
authentication allow an application to extract and reinstall the
auth state from a plugin.
We provide a method that returns a dictionary of all of the identifiable
information that is used to create a plugin. This dictionary is hashed
to uniquely identify the plugin.
We then have a get_auth_state and set_auth_state function, the return of
which is intended to be opaque to the calling application. If the plugin
created returns an ID of an existing authentication you can call
set_auth_state to load that state. If the state is out of date it will
be refreshed as per normal otherwise it will be used instead of
There is not support for caching federated tokens in this patch. They
will follow the exact same pattern and are not much harder they just
need a way for subclasses to signal they are cachable and so can be done
as a follow up.
Implements: bp cachable-auth
One of the issues raised with keystoneclient plugins is the way that
loading of a plugin is mixed in with the definition of a plugin. Amongst
other things this really meant that there was only one way to utilize
each plugin class, to do another plugin that utilized an existing one
you would have to define a new class and proxy to it.
In this patch we split the concerns. There is a whole new section called
loading that is solely responsible for ways to load the auth plugin from
CLI or from argparse and other future methods.
This new section will likely be split into its own repository.