<div dir="ltr"><div>Hi Brad,<br><br>FWIW-- I'm using AD as the LDAP backend and was using the msSFU30NisDomain attribute for the domain_id mapping. I'm now leveraging some OpenLDAP overlay magic instead, but I digress. I could see value for us in being able to leverage a domain_id stored in LDAP although admittedly we aren't yet using it. Could option 1 be implemented but be configurable? Something like "domains_enabled"? If disabled then the behavior in the default domain is used for all operations, if enabled then the current behavior is used?<br>
<br></div><div>-Aaron<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 3:56 PM, Brad Topol <span dir="ltr"><<a href="mailto:btopol@us.ibm.com" target="_blank">btopol@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Hi Folks,</font>
<br>
<br><font face="sans-serif">The current implementation of Keystone's
domain support when using LDAP as a backend is broken in the read-only
case for Grizzly. This is because Keystone in Grizzly assumes it
can create a default domain which is not possible for many read-only LDAPs.
We are trying to backport a fix for this. Basically we
have two options:</font>
<br>
<br><font face="sans-serif">1. Completely refrain from trying
to store domains in LDAP. If we run with the assumptions that most
LDAPs don't have the concept of a domain than we just assume that there
is one default domain per LDAP backend for Grizzly.</font>
<br>
<br><font face="sans-serif">2. Patch the current implementation
so that if the default domain does not exist essentially emulate having
one. This will work but will leave in storing the domain_id in an
LDAP attribute such as businessCategory (or equivalent attribute, its mappable).
This design has been seen by many as not desirable so we would like
to avoid having to leave it in if we can and then start fresh for
Havana.</font>
<br>
<br><font face="sans-serif">Ideally we would like to go with Option
1. We need to know if there are any early adopters of Grizzly that
are using keystone with an LDAP backend and using it to store multiple
domains in the LDAP. Because if we backport option 1 we will most
certainly break anyone who is using keystone with an LDAP backend
and using it to store multiple domains in the LDAP.</font>
<br>
<br><font face="sans-serif">Please provide us input on this if you
are using keystone ldap domain support!</font>
<br>
<br><font face="sans-serif">Thanks,</font>
<br>
<br><font face="sans-serif">Brad</font>
<br><font face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
<a href="tel:%28919%29%20543-0646" value="+19195430646" target="_blank">(919) 543-0646</a><br>
Internet: <a href="mailto:btopol@us.ibm.com" target="_blank">btopol@us.ibm.com</a><br>
Assistant: Cindy Willman <a href="tel:%28919%29%20268-5296" value="+19192685296" target="_blank">(919) 268-5296</a></font><br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>