Python logging is pretty amazingly flexible, and allows us to emit
to arbitrary logging domains so that a consumer can direct log output
with specificity.
Turning on HTTP debug logging currently produces an avalanche of output,
when sometimes just seeing that the requests were made and responded to
is perfectly fine.
Split the loggers used into four - one for request ids, one for request
commands, one for response headers and one for response body content.
Make them subloggers of keystoneauth.session so that if a user does nothing,
their existing logging config will be unchanged.
If someone passes in a logger, behave as before logging all things to
the provided logger.
While we're at it, document this in the using-sessions document, so that
people know that the loggers exist and what they do.
NOTE:
The tox (>=1.7.0) by default sets a random python hash seed which
causes ordering of dicts and sets to be different between tests runs.
Disabled the random python hash seed by setting PYTHONHASHSEED=0 to
fix the random failure of below test:
keystoneauth1.tests.unit.test_session.SessionAuthTests.
test_split_loggers
The PYTHONHASHSEED=0 is removed in the followup patch so that we can
separate the tracking down of ordering issues in tests from this patch.
Change-Id: Ide7dac8adf5c76c9019c35867cda632aff39770f
The previous microversion patch had some review comments from samuel and
colleen that this addresses. Also, add a release note.
Change-Id: Id83643ee5a00abc5134a88dfa5bc8ddb4f5a247a
The user now has the ability to know what microversions are available,
but needs to be able to send a microversion header with their request.
Add a microversion parameter to Session that will construct and send the
header. The microversion header requires a service_type. One should be
available but it's possible for it to be missing if someone is using an
endpoint_override. Provide a parameter to let the user specify a
service_type for the microversion call in such cases.
Change-Id: I63cdd67701749630228f9496eda82b3c8747a608
The API-WG just approved the spec for version discovery documents to
optionally provide "next_min_version" and "not_before" information.
http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
The intended use of these is to communicate that at a point in the
future the service plans to raise the minimum microversion. It can't say
when that will happen, as a service does not know when deployers will
decide to upgrade their services. But it can communicate the earliest
date it's possible to happen, which would be the first date the service
itself would raise the minimum.
This can be used to emit warnings to users who are using a microversion
less than the next_min_version and to tell them how long they have to
think about it.
Currently keystoneauth will not consume these for that purpose. This
patch is merely about collecting the information from the discovery
document if it is there so a consumer can take action on it if they
wish.
Change-Id: Ibc404ef55eeae721a0d1d16e4e3e51ad77b5a75c
get_endpoint_data on an adapater is intended to return the endpoint_data
for the endpoint the adapter is mounted to, so passing in additional
kwargs doesn't make any sense. What's more, the interaction between the
existing values and the passed in values is hard to reason about.
Update the docs on using get_endpoint_data to highlight this.
Change-Id: I851c615407bc3e22af4350a4facf8488fa9c7945
People get confused with major version discovery vs. microversion usage.
Try to make it very clear what's going on.
Change-Id: I2be8670998f531ee4777876413979a63279a59ab
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
In d0617885 the example in the Service Discovery section was changed to
include the full URL of the endpoint. On closer inspection, it turns
out that the example is deliberately pointing out that you don't need
the full URL when using endpoint filtering, since the endpoint filter
is supposed to look up the endpoint in the catalog. The reason it
wasn't working out of the box, as pointed out in the bug[1], was that
devstack sets up v2.0 endpoints, so the example path was appending /v3
to a v2.0 endpoint and failing.
This patch reverts the example back to using just a path, but omits the
'/v3' part of the path and uses the admin interface so that it will
work on v2.0. This will work out of the box on devstack and will still
work if the user has set up endpoints with '/v3' in them.
[1] https://bugs.launchpad.net/keystoneauth/+bug/1519054/comments/2
Change-Id: I11637aaa1939327eb6d1819c1b740a99e0f21e83
Reworded some sections.
Cleaned up some rst formatting. `` is for string constants, ` is for
field names.
Change-Id: Iad6c2baa5c41ed70aea1e30f677ba2682879952c
When copying this documentation over from keystoneclient we much have
simply replaced occurences of keystoneclient with keystoneauth. Details
how to migrate keystoneclient to using sessions make sense in
keystoneclient however the migration doc makes no sense in keystoneauth1
because those parameters don't exist.
Change-Id: I70160f42115d7dfe7610699479baf2e9420fe1b3
Conver from the keystoneauth namespace to keystoneauth1. This is to
ensure that is is possible to install all versions of keystoneauth
side-by-side.
Change-Id: Ibbaf11525980c8edb5968d8b8ee19c55094e77d8
This was simply the result of:
find -type f | xargs sed -i 's/keystoneclient/keystoneauth/g'
find -type f | xargs sed -i 's/python-keystoneauth/keystoneauth/g'
in the docs directory to fix the build failure.
Will look at a doc rewrite soon.
Change-Id: I05d4be12f31ea47e917dc79e50d17b174bf89938
zhouxinyong