Hi
Prior to Kilo, Keystone supported the ability for its Identity backends to be
specified on a domain-by-domain basis - primarily so that different domains
could be backed by different LDAP servers. In this previous support, you
defined the domain-specific configuration options in a separate config file
(one for each domain that was not using the default options). While functional,
this can make onboarding new domains somewhat problematic since you need to
create the domains via REST and then create a config file and push it out to
the keystone server (and restart the server). As part of the Keystone Kilo
release we are are supporting the ability to manage these domain-specific
configuration options via REST (and allow them to be stored in the Keystone SQL
database). More detailed information can be found in the spec for this change
at: https://review.openstack.org/#/c/123238/
<https://review.openstack.org/#/c/123238/>
The actual code change for this is split into 11 patches (to make it easier to
review), the majority of which have already merged - and the basic
functionality described is already functional. There are some final patches
that are in-flight, a few of which are unlikely to meet the m3 deadline. These
relate to:
1) Migration assistance for those that want to move from the current file-based
domain-specific configuration files to the SQL based support (i.e. a one-off
upload of their config files). This is handled in the keystone-manage tool -
See: https://review.openstack.org/160364 <https://review.openstack.org/160364>
2) The notification between multiple keystone server processes that a domain
has a new configuration (so that a restart of keystone is not required) - See:
https://review.openstack.org/163322 <https://review.openstack.org/163322>
3) Support of substitution of sensitive config options into whitelisted options
(this might actually make the m3 deadline anyway) - See
https://review.openstack.org/159928 <https://review.openstack.org/159928>
Given that we have the core support for this feature already merged, I am
requesting an FFE to enable these final patches to be merged ahead of RC.
Henry
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
