Red Hat Bugzilla – Bug 1300662
Keystone auth_uri set wrongly in cinder.conf
Last modified: 2016-07-31 21:04:15 EDT
Description of problem:
The option auth_uri under [keystone_authtoken] is being configured wrongly,
instead of use http://keystoneserver:5000/ is using http://keystoneserver:5000/v2.0/
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install packstack
2. Run tempest.api.volume.admin.test_volume_quotas.VolumeQuotasAdminV1TestJSON
3. It will fail due cinder.conf miss-configured
All tests related to volume is failing
All tests related to volume pass
This is not just Cinder issue, all services in Liberty should have auth_uri without API version. Parameter auth_version is used for the API version (-). Though Puppet modules are missing parameters for configuring this.
As a quickfix I'm working on workaround in Packstack and I'm going to create upstream bug for Puppet modules to fix that and submit patches for that.
I'm not completely sure this is a Packstack error.
Looking at https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L249-L254, it seems to suggest that auth_uri should contain the version, and could be unversioned based on client support.
https://github.com/openstack/cinder/commit/ffd32c7e1947189eee701c417d9f72982f720a11 states that Cinder quotas were not working correctly with Keystone v2, so that might explain the Tempest error. There is a backport to stable/liberty in progress: https://review.openstack.org/262162
I've just done an install with packstack with OSP8 and the auth_uri came out as
auth_uri = http://192.168.137.10:5000/v2.0
and i have the error. When i change it to
auth_uri = http://192.168.137.10:5000/
and restart the cinder api the error goes away.
Maybe https://bugzilla.redhat.com/show_bug.cgi?id=1290415#c2 can be of help here. The latest stable/liberty packages from Delorean for Cinder fixed the issue in RDO.
Please disregard my previous comment, wrong bug :-(.
Adam, I see much confusion here, could you please explain what's the story with auth_* parameters and why is there auth_version at all? Identity API version is supposed to be negotiated between Keystone and the client right?
"The issue referenced by the bz was fixed already on the Cinder side, and this patch seems to be breaking other functionality."
"This patch" := https://review.openstack.org/275317
Both were Packstack master only https://review.openstack.org/#/q/topic:Ie4582616459434830aa23cb0a668224e23adf234 and were not backported so OPS8 / Liberty is not affected.
There is always a lag between the changes and recommendations put out by the Keystone team and the adoption of those recommendations by the other services. THe goal has been to get the services to use the Keystone V3 API when communicating with the Keystone server to authenticate tokens. This can be done either by hardcoding the URI to be v3 and specifying a V3 auth plugin, or by using discovery. The discover method is preferred. However, I am not certain what the puppet modules or packstack are actually setting during install.
The Cinder RPM seems to code the following values into
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
This was the original way of specifying the Keystone server. These values were then built into the auth_uri.
Today we prefer specifying the whole auth_url, and this should take precedent;
For example, a recent deploy of mine has:
auth_uri = http://192.0.2.6:5000/v2.0
Which is what is used. This is hard coded to the V2 api, and not what we want long term.
If we specify
auth_uri = http://192.0.2.6:5000/
we would have the same thing
and to force to v3
Better to let negotiation take place, and the client can select the appropriate version.
The best way, and what is now done, is to specify the values used to make an auth plugin.
This calls for
instead of auth_url, but I am not clear on why the different term was needed. I suspect it was to not break backwards compatibility.