Open Stack

The current Domain implementation breaks most people's LDAP backends, 
because it hijacks and attribute, and there is no attribute guaranteed 
to be present but unused.


On 04/25/2013 10:56 AM, Simo Sorce wrote:
> On Thu, 2013-04-25 at 10:45 -0400, Adam Young wrote:
>> OK,  so Ryan has convinced me that multiple LDAP servers under the same
>> Keystone is an incantation for self induced insanity.
>>
>> Based on conversations with the other devs, we are going to enforce that
>> there is only one LDAP server per keystone, and limit the number of
>> domains it can support to one.
>>
>> There can be only one.
> I would like to hear what is the argument that convinced you here ?
>
> The reason you have multiple domains is that you have the need for
> multiple user-sets, that seem to lend naturally to cover the case where
> an organization have multiple set of users in different LDAP servers, so
> that you may want to use one LDAP server for one domain and another for
> another domain.
>
> Where does this argument breaks ?
It is not that LDAP ibn general can't support domains, but rather that 
the way people are using LDAP in Open Stack can't support domains.

LDAP is read only, multi application data.  We can't impose schema. 
We've pretty much pushed the limits of what we can do in a 
"one-size-fits-all" approach, and domains exceeds that.

>
>> The APIs for Domains will still be implemented, but creating or
>> modifying a domain will be return an Not implemented return code. There
>> will be a single domain object that will be immutable, although we may
>> allow initializing it from config file values.
> Oh, so no support for multiple domains at all ? Odd, seem this will make
> your LDAP backend a second class citizen and a non viable choice in some
> deployment. Not complaining just acknowledging.
See the below paragraph that starts "Organizations that require multiple 
LDAP".

When pressed, the people that are asking for multiple LDAP backends into 
the same keystone server have admitted that they are looking to keep the 
other backends separate as well, esepcially the token backend. Thus, it 
makes sense to have a solution for supporting multiple Keystone servers 
in an Open Stack deployment, and having each LDAP server fronted by its own.

>
>> Why are we "yanking" a feature like this? Quite simply, because the vast
>> majority of LDAP deployments out there will not use it, and will not
>> support the approach we have started.  We would rather focus on solving
>> the real needs of the LDAP users.  Most people cannot write to their
>> LDAP servers, and those that can often don't have the power to change
>> the schema.  Thus far, the LDAP work has kept this design in mind, but
>> Domains forced us to marry up two inconstant views of the world.
>>
>> Multiple domains will still be supported in the SQL backend.
>>
>> Organizations that require multiple LDAP servers were not served by the
>> existing implementation.  Those will require a different solution. Each
>> will get their own Keystone server, and we will use the approach
>> sketched out in other blueprints to ensure that they can co-exist in a
>> single Open Stack deployment.
> I guess the read-only LDAP case can still be used for multiple domains
> if keystone specific data is kept in a Kystone database ?
It could be, but it requires a special schema, and we cannot force that 
on anyone.

We could build a solution that involves:

Multiple database backends, and a different mapping per LDAP server, but 
it is not going to happen quickly.
>
> If that's the case I think your choice will make sense.
>
> Simo.
>