Hi Brad, 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?
-Aaron On Tue, May 7, 2013 at 3:56 PM, Brad Topol <bto...@us.ibm.com> wrote: > 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: bto...@us.ibm.com > Assistant: Cindy Willman (919) 268-5296 > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp