Open Stack

On 07/23/2013 12:15 PM, Alexius Ludeman wrote:
> hi Adam,
>
> Can you explain why RoleApi() and ProjectApi() are duplicated 
> in assignment/backends/ldap.py and identity/backends/ldap.py?
>
> It would seem duplicating the same class in two files should be 
> refactored into new shared file.

That is the "backwards compatbility" I was referring to earlier. Roles 
and Projects are now owned by the assignment API, but have been accessed 
via the Identity backend up until now.  Thus, the Identity 
implementation should be nothing but a shim to call the assignment 
implementation.

>
> thanks
> lex
>
>
>
> On Tue, Jul 23, 2013 at 7:21 AM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     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
>>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto: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/20130723/809ceed1/attachment.html>