Open Stack

OK, so Henry's document, while sound, it actually specifies a schema.  
It is what a sane person would do, but LDAP drives away sanity.  We know 
that for most people, wae can't dictate what the schema would look like.
So, if there is a need for "manging multiple domains from a single 
Backend" we will try to migrate over to useing Henry's design.  It was 
what I wanted in the first place.

If there is a customer out there that wants to use LDAP with a schema 
that matches Henry's design, we still have to account for the fact that 
not everything under a single root can be considered a domain.  There 
may be no root entity, or there might be things under their root entity 
that is not a domain, but that still implements orgUnit.

Make that one reason in support of the external JSON config for domains.

Lets look at the requirement that  a single Keystone front multiple LDAP 
servers.  These are not going to be dynamically definied. It is going to 
be a small, fixed  number of LDAP servers, with one being added or 
removed on average of every couple of years.  We need a place to 
configure these.

That is two reasons in support of an external JSON config file

Now, lets take the case where two organizations have one cloud, but they 
want to maintain their user data completely separately. Different LDAP 
server, different Token database, and maybe even an overlapping but 
different set of endpoints.  These two Keystone servers need a way to 
talk to each other.  Each gets registered as an "external" domain in the 
JSON file.

Hence:  https://etherpad.openstack.org/chain-of-domains


Its clean.  It is straightforward, and it allows the backends to 
interoperate.  If we decide to cut some aspect of scope, it still 
supports the other use cases.

We probably want to discuss it in context with

https://blueprints.launchpad.net/keystone/+spec/json-for-ldap

https://blueprints.launchpad.net/keystone/+spec/multiple-datastores