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 <[email protected]> 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:[email protected] <[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] <[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 > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
