Open Stack

I need to go read Henry's  document. I can't comment on that yet.  In 
principle, I am OK with having a separate json config file for doing the 
LDAP configuration.  I agree that we will be adding enough content here 
that its probably best to move it out of keystone.conf.   We do however 
need to look at the config options apache provides for this as we will 
benefit from its experience.  For the chain of domains work I'm pretty 
sure I can get you some stakeholders and use cases.   We definitely have 
folks interested in getting multiple keystones to work together. Starting 
the planning/design of this work has the best chance of being 
successful/providing value if we get the stakeholders and concrete use 
cases first and then go from there.

Thanks,

Brad

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



From:   Adam Young <ayoung at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   04/26/2013 05:25 PM
Subject:        Re: [openstack-dev] [keystone] Suggested LDAP DIT for 
domains



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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130428/4f5623a4/attachment.html>