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.
Change-Id: Ie623931b150748d7759cf276e0023a2f06a8d4db
We expect endpoint_override, but these plugins won't necessary
have it, they have endpoint instead.
Co-Authored-By: Dmitry Tantsur <dtantsur@protonmail.com>
Change-Id: Iead4b95c1f5b8d84cec705da32f41049e2eea641
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
None object.
Change-Id: I06ad497854f4e95a1a2a4a93241b244fc476b139
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.
Change-Id: I08f8989e335e442787fa4c75497ee4be3a1ec35a
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
either:
a.get_api_major_version()
or:
a.get_endpoint_data()
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
context.
Change-Id: Id9bd19cca68206fc64d23b0eaa95aa3e5b01b676
Currently tox ignores D400 (D400: First line should end with a period).
This change removes D400 ignore.
All pep8 violatios are fixed.
Change-Id: I9190a15a36c90d3c60a9c520cb53d5f182b0c4e9
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.
Change-Id: I8cf0f54cdec358238774636ba1d42f11e7ace555
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
authenticating again.
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
Change-Id: I4eebe7ff8060a37f19af5decfa3a8313cfb7c207
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.
Change-Id: I8387b86fc0e3a8403f9806440196e8723eaf1ee4
Dmitry Tantsur