<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi<div class=""><br class=""></div><div class="">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: <a href="https://review.openstack.org/#/c/123238/" class="">https://review.openstack.org/#/c/123238/</a></div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">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: <a rel="nofollow" href="https://review.openstack.org/160364" style="max-width: 60em; color: rgb(0, 51, 170); text-decoration: none; font-family: sans-serif; line-height: 18px;" class="">https:/<wbr style="max-width: 60em;" class="">/review.<wbr style="max-width: 60em;" class="">openstack.<wbr style="max-width: 60em;" class="">org/160364</a></div><div class="">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: <a rel="nofollow" href="https://review.openstack.org/163322" style="max-width: 60em; color: rgb(0, 51, 170); text-decoration: none; font-family: sans-serif; line-height: 18px;" class="">https:/<wbr style="max-width: 60em;" class="">/review.<wbr style="max-width: 60em;" class="">openstack.<wbr style="max-width: 60em;" class="">org/163322</a></div><div class="">3) Support of substitution of sensitive config options into whitelisted options (this might actually make the m3 deadline anyway) - See <a href="https://review.openstack.org/159928" class=""><font color="#0033aa" face="sans-serif" class=""><span style="max-width: 60em; line-height: 18px;" class="">https:/</span></font><font color="#0033aa" face="sans-serif" class=""><span style="max-width: 60em; line-height: 18px;" class=""><wbr style="max-width: 60em;" class="">/review.<wbr style="max-width: 60em;" class="">openstack.<wbr style="max-width: 60em;" class="">org/159928</span></font></a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Henry</div></body></html>