thanks
lex
On Tue, Jul 23, 2013 at 7:21 AM, Adam Young <ayo...@redhat.com
<mailto:ayo...@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:ayo...@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:ayo...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
