On 07/22/2013 09:49 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
Adam,
Sorry for the questions, but even though I have been programming for
nearly 30 years I am new to Python and I find the code base somewhat
difficult to follow. I have noticed that the file
keystone.identity.backends.ldap.Identity has a set of methods and file
keystone.assignment.backends.sql.Assignment has a set of methods. My
question is this: is there a way to specify which methods to use the
ldap.Identity backend with and which methods to use the sql.
Assignment backend with or does each backend only support all of the
methods provided by each file? In working with an enterprise LDAP
server, there is no way we will be able to create users or to write to
it. If there is a way to pick and choose which methods access the LDAP
server and which ones access the SQL keystone database, then I have
what we need.
Here's the general gist:
We split off the Assignment functions from Identity in order to be able
to vary the two backends independently. THe expectation is that
people will use the LDAP backlend for Identity and the SQL backend for
Assignments. LDAP will be read only, and Assignments will be
read-write. That being said, there are cases where people will have
writable LDAP, or will use the SQL Identity backend, so there are
functions which can change the state of the Identity backend, and those
are not going to go away.
The general code set up is as follows:
Routers describe the mappings from URLs to Python Code.
Controllers ate stateless objects. In theory they should be protocol
agnostic, but in practice they are aware that they are being used with HTTP.
Managers and Drivers implement the Data layer. The managers start as
simple accessors, but over time they get more and more logic. We don't
have a clear place for Business logic. Since the Backends are radically
different, a lot of the logic has gotten duplicated between LDAP, SQL,
Memcahced, and others. We are working to minimize this. The general
approach is that code that should not be duplicated gets "pulled up" to
the manager. This kind of refactoring is constant and ongoing.
When I split out the Assignment backend, I tried to to it in a way that
did not modify the unit tests, so that other reviewers would have
theassurance that the chagnes were just restructuring, not
fundamentally changing functionality. Thus, we had a shim layer in the
Identity Layer that called through to the assignment layer. This has the
added benefit of maintaining API compatibility for anyone who has
customized code. However, I've found a lot of our tests were talking to
the driver, not talking through the manager, and thus I had to clean up
a bunch of the tests to go through the manager as well.
As an end user, you should specify that the Identity backend is LDAP and
the Assignment backend is SQL. Assuimg your LDAP backend is not
writable, and call to the Identity layer that attempts to morph the
state of the Directory store will fail. However, what you should be
doing is using the user groups from LDAP as a way to manage users, and
place those groups into Role Assignments. Roles, Role Assignments, and
Projects all live in the Identity (SQL) backend, and all of those should
be writeable regardless of LDAP state.
Thanks,
Mark
*From:*Adam Young [mailto:[email protected]]
*Sent:* Monday, July 22, 2013 4:52 PM
*To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
*Cc:* Dolph Mathews; OpenStack Development Mailing List
*Subject:* Re: [keystone] Split the Identity Backend blueprint
On 07/22/2013 07:43 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
Adam,
You wrote:
[identity]
driver = keystone.identity.backends.ldap.Identity
[assignment]
driver = keystone.assignment.backends.sql.Identity
Did you mean to write:
[assignment]
driver = keystone.assignment.backends.sql.Assignment
Yes, that was a mistake on my part. Sorry
Mark
*From:*Adam Young [mailto:[email protected]]
*Sent:* Monday, July 22, 2013 12:50 PM
*To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
*Cc:* Dolph Mathews; OpenStack Development Mailing List
*Subject:* Re: [keystone] Split the Identity Backend blueprint
On 07/22/2013 01:38 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
Hello,
I have been reading source code in an attempt to figure out how to
use the new split backend feature, specifically how to split the
identity data between an ldap server and the standard Keystone sql
database. However, I haven't been able to figure it out quite yet.
Does someone have some examples of this new feature in action? Is
there another configuration file that is required?
[identity]
driver = driver = keystone.identity.backends.sql.Identity
[assignment]
driver = ???
[ldap]
Quite a few options
Regards,
Mark Miller
RIght now the only support split approach is LDAP for Identity, SQL
for assignments.
[identity]
driver = keystone.identity.backends.ldap.Identity
[assignment]
driver = keystone.assignment.backends.sql.Identity
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
