openstack
/
keystone
Code Issues Proposed changes

Improve keystone.conf [identity_mapping] documentation 

Change-Id: Ie7957661d9f5108f9c92ea414ffbbd39436d07d0
This commit is contained in:
Dolph Mathews 2016-06-29 16:42:51 -05:00
parent 4eb93c070f
commit 2917c4db3c
1 changed files with 22 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
keystone/conf/identity_mapping.py
View File

@ -19,17 +19,21 @@ driver = cfg.StrOpt(
'driver',
default='sql',
help=utils.fmt("""
Entrypoint for the identity mapping backend driver in the
keystone.identity.id_mapping namespace.
Entry point for the identity mapping backend driver in the
`keystone.identity.id_mapping` namespace. Keystone only provides a `sql`
driver, so there is no reason to change this unless you are providing a custom
entry point.
"""))
generator = cfg.StrOpt(
'generator',
default='sha256',
help=utils.fmt("""
Entrypoint for the public ID generator for user and group entities in the
keystone.identity.id_generator namespace. The Keystone identity mapper only
supports generators that produce no more than 64 characters.
Entry point for the public ID generator for user and group entities in the
`keystone.identity.id_generator` namespace. The Keystone identity mapper only
supports generators that produce 64 bytes or less. Keystone only provides a
`sha256` entry point, so there is no reason to change this value unless you're
providing a custom entry point.
"""))
backward_compatible_ids = cfg.BoolOpt(
@ -37,17 +41,20 @@ backward_compatible_ids = cfg.BoolOpt(
default=True,
help=utils.fmt("""
The format of user and group IDs changed in Juno for backends that do not
generate UUIDs (e.g. LDAP), with keystone providing a hash mapping to the
underlying attribute in LDAP. By default this mapping is disabled, which
generate UUIDs (for example, LDAP), with keystone providing a hash mapping to
the underlying attribute in LDAP. By default this mapping is disabled, which
ensures that existing IDs will not change. Even when the mapping is enabled by
using domain specific drivers, any users and groups from the default domain
being handled by LDAP will still not be mapped to ensure their IDs remain
backward compatible. Setting this value to False will enable the mapping for
even the default LDAP driver. It is only safe to do this if you do not already
have assignments for users and groups from the default LDAP domain, and it is
acceptable for Keystone to provide the different IDs to clients than it did
previously. Typically this means that the only time you can set this value to
False is when configuring a fresh installation.
using domain-specific drivers (`[identity] domain_specific_drivers_enabled`),
any users and groups from the default domain being handled by LDAP will still
not be mapped to ensure their IDs remain backward compatible. Setting this
value to false will enable the new mapping for all backends, including the
default LDAP driver. It is only guaranteed to be safe to enable this option
if you do not already have assignments for users and groups from the default
LDAP domain, and you consider it to be acceptable for Keystone to provide the
different IDs to clients than it did previously (existing IDs in the API will
suddenly change). Typically this means that the only time you can set this
value to false is when configuring a fresh installation, although that is the
recommended value.
"""))