openstack/swift
Code Issues Proposed changes

Add more comment to authtoken sample options

Browse Source 
Prior to the Mitaka release the install guides showed
services (including Swift) being in a default Keystone
domain which existed by default and has id=default. This
domain id is reflected in the proxy-server.conf-sample
authtoken options and also shown in man page and auth docs.

The Mitaka install guide shows a domain with *name* default
being created, and having a random UUID assigned, in which
services are created. This has caused confusion (see
discussion on linked bug report).

This patch does not change the sample options but does
add to the comments in order to emphasize that a user
may need to alter the options to match their Keystone
configuration.

Change-Id: I17bfcdbd983402eeb561bb704b8b1f1e27547c7d
Partial-Bug: #1604674
This commit is contained in:
Alistair Coles 2016-09-19 16:06:18 +01:00
parent 2355771d4b
commit 18bb99971f
3 changed files with 22 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/manpages/proxy-server.conf.5
View File

@ -286,6 +286,14 @@ You'll need to have as well the keystoneauth middleware enabled
and have it in your main pipeline so instead of having tempauth in
there you can change it to: authtoken keystoneauth
The auth credentials ("project_domain_name", "user_domain_name", "username",
"project_name", "password") must match the Keystone credentials for the Swift
service. The example values shown here assume a user named "swift" with admin
role on a project named "service", both being in the Keystone domain with id
"default". Refer to the KeystoneMiddleware documentation at
.BI http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html#configuration
for other examples.
.PD 0
.RS 10
.IP "paste.filter_factory = keystonemiddleware.auth_token:filter_factory"

10
doc/source/overview_auth.rst
View File

@ -131,7 +131,7 @@ Configuring Swift to use Keystone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Configuring Swift to use Keystone_
is relatively straight forward. The first
is relatively straightforward. The first
step is to ensure that you have the ``auth_token`` middleware installed. It can
either be dropped in your python path or installed via the KeystoneMiddleware_
package.
@ -181,7 +181,13 @@ your situation, but in short:
* The auth credentials (``project_domain_id``, ``user_domain_id``,
``username``, ``project_name``, ``password``) will be used to retrieve an
admin token. That token will be used to authorize user tokens behind the
scenes.
scenes. These credentials must match the Keystone credentials for the Swift
service. The example values shown here assume a user named 'swift' with admin
role on a project named 'service', both being in the Keystone domain with id
'default'. Refer to the `KeystoneMiddleware documentation
<http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html#configuration>`_
for other examples.
* ``cache`` is set to ``swift.cache``. This means that the middleware
will get the Swift memcache from the request environment.
* ``include_service_catalog`` defaults to ``True`` if not set. This means

6
etc/proxy-server.conf-sample
View File

@ -327,6 +327,12 @@ user_test5_tester5 = testing5 service
# auth_uri = http://keystonehost:5000
# auth_url = http://keystonehost:35357
# auth_plugin = password
# The following credentials must match the Keystone credentials for the Swift
# service and may need to be changed to match your Keystone configuration. The
# example values shown here assume a user named 'swift' with admin role on a
# project named 'service', both being in the Keystone domain with id 'default'.
# Refer to the keystonemiddleware documentation link above [1] for other
# examples.
# project_domain_id = default
# user_domain_id = default
# project_name = service