Open Stack

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:ayoung at redhat.com]
> *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:ayoung at redhat.com]
> *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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/8dd331c2/attachment.html>