openstack team mailing list archive

[Brad Topol <btopol@xxxxxxxxxx>]

Hi Folks,

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:

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.

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.

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.

Please provide us input on this if you are using keystone ldap domain 
support!

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol@xxxxxxxxxx
Assistant: Cindy Willman (919) 268-5296