<font size=2 face="sans-serif">Hi Folks,</font>
<br>
<br><font size=2 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 size=2 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 size=2 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 size=2 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 size=2 face="sans-serif">Please provide us input on this if you
are using keystone ldap domain support!</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Cindy Willman (919) 268-5296</font>