<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" dir="auto">Rich,<div class=""><br class=""></div><div class="">Yes, I am adding this ability to the keystone client library and then to osc.</div><div class=""><br class=""></div><div class="">Henry<br class=""><div><blockquote type="cite" class=""><div class="">On 17 Mar 2015, at 20:17, Rich Megginson <<a href="mailto:rmeggins@redhat.com" class="">rmeggins@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 03/17/2015 01:26 PM, Henry Nash
wrote:<br class="">
</div>
<blockquote cite="mid:8CE2BB79-1A5E-4363-B23C-4EE5FEB08F5F@linux.vnet.ibm.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" href="https://review.openstack.org/159928" class=""><font class="" color="#0033aa" face="sans-serif"><span style="max-width: 60em; line-height: 18px;" class="">https:/</span></font><font class="" color="#0033aa" face="sans-serif"><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>
</blockquote>
<br class="">
This would be nice to use in puppet-keystone for domain
configuration. Is there support planned for the openstack client?<br class="">
<br class="">
<blockquote cite="mid:8CE2BB79-1A5E-4363-B23C-4EE5FEB08F5F@linux.vnet.ibm.com" type="cite" class="">
<div class=""><br class="">
</div>
<div class="">Henry</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br class="">
</div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>