This is no longer necessary since we only support Python 3.x.
A note is removed from requirements.txt since it's no longer relevant:
pip 20.3+ has a real dependency resolver.
Change-Id: Ie3006813a79fef1f128d388b906e4f1752347fa4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Co-Authored-By: Grzegorz Grasza <xek@redhat.com>
The get_all_version_data method is useful for getting a full listing of
what's going on with version discovery on a cloud. Sometimes though
people just want to see the versions for a specific service. Add a
filter to allow skipping making the version discovery call in the first
place, instead of needing to do that as a post-filtering step.
Change-Id: Ia3ca4be2976d1a5e7914fa8f2adbf7297e8cb1e1
Setting up an Adapter with an endpoint_override, calling
get_endpoint_data() on that adapter, and accessing the `url` @property
of the resulting EndpointData now regurgitates the endpoint_override
initially set on the Adapter.
Change-Id: I1033c97a7b0e19a75fa0d3c5682cf18b75918514
Closes-Bug: #1707993
The last piece of service type alias support is to handle volumev2,
volumev3, workflowv2, workflowv3 and friends.
Although it's an annoying scenario, luckily legacy code that uses them
has a clear meaning. volumev2, version='3' is just legit not a thing.
Needed-By: https://review.openstack.org/564494
Change-Id: Iec09bcb16d8e9b09e09bf12d03c2a55e679ad70c
We're repeating ourselves a bunch with a plain dict that contains the
version data. Make a class to encapsulate it. Make the class a subclass
of dict so that json translation works.
Change-Id: Ic7d122487174a5b0378a8dfaa39514c5cb2a604b
We've got great discovery support, but if someone is wanting to find out
what is available and doesn't otherwise know what they're looking for,
they're out of luck.
Add a method to EndpointData which will return all of the version data
for a given service, and then add a method to the base auth plugin that
will use that method to collect all of the version discovery documents
for every service in the cloud.
This commit adds os-service-types so that the resulting datastructure
can return only official service type keys. A followup patch will also
use os-service-types to allow catalog lookups by service-type alias.
There is a change to the test_identity_common.V2.get_auth_data method
to remove the public and internal urls for keystone from the catalog.
The V3 catalog only has keystone on admin, so this makes them have
equivilent data.
Change-Id: I07243edb939865a5df8b283e7c626874ffd830db
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
Similar to get_endpoint, which knows it doesn't need full endpoint_data,
if a user just wants to know what major version the discovery process
wound up with, there are cases in which we do not need to fetch
discovery documents. Provide an API call that a user can use when this
is the information they need to avoid them having to play games with
discover_versions settings.
Change-Id: I204a45d1d139a90176bcc2ef8d46decd09b2cd5b
The positional decorator results in poorly maintainable code in
a misguided effort to emulate python3's key-word-arg only notation
and functionality. This patch removes keysteonauth's dependance
on the positional decorator.
Change-Id: I20106345747860365cd0203ba1b33a2900e045b9
We're discouraging the use of the ambiguous and difficult-to-understand
'version' parameter in new discovery methods, instead encouraging the
use of min_version and max_version.
In order to make it possible to get the same functionality, though, we
need a way to say the same thing as version="M.m", which actually means,
"min version is M.m, and max version is the latest within major version
M".
Introducing 'latest' syntax, which can be used in various ways,
including:
min_version='2.3', max_version='2.latest'
...which is equivalent to the old school version='2.3'
Change-Id: Ife842333e25c33e54bbae4c1adb101014cb8e8db
Remove unused `authenticated` kwarg from as-yet-unreleased public API
EndpointData.get_versioned_data, and private method
EndpointData._set_version_info.
Change-Id: I03a9969df4586c79b6b63d44fcb5474dd94e6ba2
Closes-Bug: #1703446
There are a two interrelated pieces in this patch which are around
fixing up places where discovery was being re-run inappropriately.
They fall out from adding tests for the functionality and couldn't
be sanely shifted back further in the stack without a big dance.
Switch the default for "discover_versions" on all of the calls that
return an EndpointData to "True". It's a new feature and is a thing that
doesn't make a ton of sense to call if you don't want discovery run.
However, get_endpoint uses it, so needs to be able to pass in
discover_version=False, so the option is still useful. Make sure that
get_endpoint and other places where ksa calls get_endpoint_data on
behalf of the user work as before without unneeded discovery.
Add tests to show that we use actually use the discovery cache properly when
we've previously done discovery that can satisfy the new request. This
works from the microversion optimization patch, but we had to clean up
a couple of things to show it fully in a test.
Change-Id: I54053336edf1b3c2bd35a77dbd78f56388b8e806
Sometimes, especially in places like service-to-service defaults, it's
very helpful to express a list of values. For instance, when thinking
about nova connecting to ironic, nova would like to have the default
value of "interface" be ['internal', 'public'] - which is to say, use
internal if it's there, but otherwise use public. This use case is covered
in the API-WG specs on discoverability.
Change-Id: I9102155c2d4ef1ef8bbb1d0fa26a5b5838108a4c
In the case where we're just asking for an endpoint, and the endpoint in
the catalog matches the requested version, there is no need to fetch the
version discovery document.
Change-Id: I2c14337a3fcb1369652d43ca68e6a572fef6d425
If a user has provided an endpoint_override, they may still be
interested in version discovery data for the endpoint. Doing that is
always an opt-in behavior, so we set the strictness flag to prevent any
URL manipulations. We'll either return data or None.
Change-Id: I673beafd1e55fd096bb221b2ca6794bb124653b8
Just wanting "latest" isn't the full picture. A client could support,
say, v1 and v2 of an API but not v3 and would like to find an
appropriate matching endpoint.
Add two new arguments, min_version and max_version, rather than
repurpose the version argument.
This changes the behavior of versioned_data_for and versioned_url_for in
the case where version=None. Before that would return None, now it
returns the information about the endpoint that was in the catalog.
The booleans in this are a bit hard to read, as are the fun times with
latest and things being or not being defined. It's time to make the
versions into objects, but we'll do that as a followup.
Change-Id: I8ba948a712002775098b0a86c70f05e0c68250f5
If a user does not specify a version, that means they want whatever is
in the catalog. However, they may still want discovery to be run for
things like microversion information. The new parameter
"discover_versions", if set to True, will run discovery even with no
version parameter. The inverse of this is "skip_discovery" which will
tell keystoneauth to not run discovery even if a version has been given.
Note: This adds some parameters to some methods that get removed by
change I54053336edf1b3c2bd35a77dbd78f56388b8e806 so we should not
actually land this one until we're ready to land the stack up to and
including that one.
Note: This adds two new methods that will have behavior changes in
patch I8ba948a712002775098b0a86c70f05e0c68250f5.
Change-Id: I897c39743089c5994b51336a4ad44eebed33ec35
From the API-WG spec, there are two common patterns for service URLs
that can be interpreted. Trailing project_id and a string that starts
with v. If the project_id is in the URL, it needs to be removed before
discovery can happen, but it needs to be put back on to the url found
via discovery. If the endpointin the catalog has a version, and it
matches the version we're asking for, then we don't need to go hunting
for the unversioned doc.
Also, in the EndpointData we're collecting, we want to grab microversion
info, since we're already there in the discovery doc.
There is one behavior change that can be seen in the tests. If the
attempt at an unversioned discovery endpoint fails, we fall back to the
url from the catalog ... but we attempt to get a discovery document from
it because we need the metadata for microversions. The catalog URL should be
returned as the endpoint even if the second discovery call attempt
succeeds, so the user-facing interface is the same - there will just be,
in some cases, an additional URL fetch behind the scenes.
Change-Id: I2a036d65e4f7dba6f50daf6a0ce4589ee59ae95f
As part of implementing the API-WG spec on version discovery, there are
more version manipulations and logic that need to happen between
fetching from the catalog and doing discovery.
Move the logic for doing that into the discovery file and attach it to
the EndpointData object.
This changes 2 interfaces, but neither of those interfaces have been in
a release.
The method "discover_versions" is renamed to "get_versioned_data" - since
the work it does is actually to get a versioned EndpointData object.
It also now returns a new EndpointData object instead of mutating the
existing one. Especially with the name change, mutation seemed really
off.
Change-Id: Ifeeac7af1ebd9d2d59a30d4503c8bcc0137e9370
Allow the user to pass in a cache dict that will be used
in addition to the session and auth level caches. Make Session
always have a discovery_cache attribute and allow the user to
provide the cache at Session creation time. Finally, rename
the private variable to _discovery_cache from _endpoint_cache
since it's caching discovery objects, not endpoints.
Co-Authored-By: Samuel de Medeiros Queiroz <samueldmq@gmail.com>
Change-Id: I0a0f489fd3bbecc4596e99acafcde1bff4e181f7
The existing version discovery process is awesome, but in the normal flows it
ultimately returns urls, not the full endpoint data, so it's not
possible to know what version was discovered.
Make an EndpointData object that gets created and plumb that through the
stack so that it's possible to request EndpointData instead of just
endpoints. The existing discovery logic is unchanged, and the existing
methods continue to return the data they returned before.
Change-Id: Id48861e7d6d20be16f61cb375a21bca4a43a2500
Whilst historically we always wanted keystoneauth to do the most
permissive thing and allow a versioned or unversioned entry in a service
catalog there are now cases where we would prefer to fail when the
catalog is misconfigured. This will allow a client to opt out of
versioned catalog endpoints to insist that the deployment is correctly
configured.
Closes-Bug: #1668484
Change-Id: Ided0e0c7409994f703175fe61bd4043b840bcf1e
1.As mentioned in [1], we should avoid using
six.iteritems to achieve iterators. We can
use dict.items instead, as it will return
iterators in PY3 as well. And dict.items/keys
will more readable. 2.In py2, the performance
about list should be negligible, see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
Change-Id: I9f8f2c35f0d45d866076507a3a167aaafb8382e5
After patch Ia08538ccf00c9063dc0d284c5ece9a969c15500a the urljoin would
ensure that a URL was always returned from the get_endpoint method even
when the version was not available. This breaks plugin discovery and a
number of other areas.
Change-Id: I04014b6e770c2e9708c5f9c81c3160d51603ad0c
Closes-Bug: #1616720
When using a reverse proxy or TLS terminator it can be really hard to
correctly specify a URL in version discovery that is correct for all
situations.
Make it so that a relative URL in a discovery document is joined to the
queried URL to always return a fully qualified URL to the identity
plugins.
Change-Id: Ia08538ccf00c9063dc0d284c5ece9a969c15500a
Closes-Bug: #1614304
The Discover class can fiilter API versions by experimental status, deprecated
status, and unknown status, and potentially more designations in the future.
The parameters that control this were not exposed in the Session or Adapter, so
users could not take advantage of this filtering through normal means. This
patch creates an 'allow' parameter for the Adapter that will get passed down as
keyword arguments into Discover.raw_version_data().
Now, given an unversioned endpoint like:
$ openstack endpoint show cinder
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| adminurl | http://192.168.122.183:8776 |
| enabled | True |
| id | 485107c1d92b41829c331a2dc82aaaeb |
| internalurl | http://192.168.122.183:8776 |
| publicurl | http://192.168.122.183:8776 |
| region | RegionOne |
| service_id | 01b4f36a173d4c59b31fc95763095373 |
| service_name | cinder |
| service_type | volume |
+--------------+----------------------------------+
an Adapter can be used like this (this example would be expected to fail
since it disallows the deprecated volume V1 API):
auth = Password(<auth_params>)
sess = session.Session(auth=auth)
adptr = adapter.Adapter(sess)
adptr.get('<project-id>/volumes',
endpoint_filter={'service_type': 'volume',
'interface': 'public',
'version': 1},
allow={'allow_deprecated': False}))
This is inspired by an abandoned patch to keystoneclient[1] that exposed this
information as a tuple. The problem with exposing it like that is that
raw_version_data() defaults allow_deprecated to True, so including 'deprecated'
in the tuple or not including it would have the same result. Using a dict
allows us to keep the Discover interface the same.
[1] https://review.openstack.org/#/c/130159
Co-authored-by: Endre Karlson <endre.karlson@hp.com>
Change-Id: I54c29e1c2a4a2b02a3967f4ea108b8d2533616eb
Closes-bug: #1394245
Several of these docstrings were referring to classes that didn't
exist. For example, they referenced keystonauth which doesn't
exist and is supposed to be keystoneauth1.
Change-Id: I070d32937c11b111f1821c466e8dfe55caadd748
The positional library was spun directly out of what keystoneauth1 was
using so this is a fairly trivial change.
Change-Id: I7931ed1547d2a05e2d248bc3240a576dc68a0a40
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
A common case is for Nova (or other service) to create an admin
authentication from a CONF file and then have many greenlet threads that
want to reuse that authentication. If a token expires then many threads
all try and fetch a new token to use and can step over each other.
I was hoping for a way to put a lock in so that all plugins were thread
safe however fixing it for identity plugins solves almost all real world
situations and anyone doing non-identity plugins will have to manage
threads themselves.
Closes-Bug: #1493835
Change-Id: Ie478499a086a4b0db4fb9e5b820f6f5cd4074763
As keystoneauth comes out with new releases, it would be
convenient if the logger name did not change.
Change-Id: Ica4102db27fa6cd2a3eaa1dac647abe02b4543a2
We've been trying to move people onto using interface rather than
endpoint_type for a while as interface is what is talked about in all
the API docs and is what is exposed by the clients.
Rename all occurrences of endpoint_type with interface.
Change-Id: If18d8e27e499c294cb4dc94521da843341287362
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
The /auth directory made sense when we were seperating the plugins from
the rest of keystoneclient, however now we are in keystoneauth there
really is no need for the auth subdirectory.
Change-Id: I94f12780af4f914ead93796a052e9dc82c6c2f81