Open Stack

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.

thanks
lex



On Tue, Jul 23, 2013 at 7:21 AM, Adam Young <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 <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 <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
> 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/9bb1cc28/attachment.html>