On 08/07/2013 08:05 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
I have been thinking about the keystone user lookup GET API for a
split LDAP/SQL backend when you are using a read only LDAP backend:
http://15.253.58.165:35357/v3/auth/tokens
A suggestion has been made to add additional lookup constraints via a
filter. The problem with read only LDAP databases is that you are not
able to tag the keystone users with any flags to indicate that they
are keystone users. The current Keystone H-2 LDAP backend code
performs the _ldap_get_all function (which took 1 ½ hours today) and
must then look to see which of those users are in the keystone
database because the REST API call only returned the one user that I
had assigned a project role to. I am thinking that this logic is
backwards. Instead of starting with the LDAP server, start by querying
the keystone SQL database for LDAP users and then query the LDAP
system for those users a certain number at a time (good use of
pagination). By the way, I am assuming that keystone finds the LDAP
users by looking in the user_project_metadata, user_group_membership_
anduser_domain_metadata tables for user IDs that are not in the user
table.
We should probably just drop the list_user functionality from Keystone,
as it probably doens't belong there. listing users in a project it
probably fine, but all users in the system only makes sense for really
trivial systems.
Most LDAP servers limit the number of records returned. I know in
FreeIPA, we had 200 records, and then you needed a filter to find what
you wanted beyond that. Pagination is a bettersolution, although I
shudder to think of the impact of all those live cursors on a heavily
loaded Enterprise directory.
Mark
*From:*Dolph Mathews [mailto:[email protected]]
*Sent:* Wednesday, August 07, 2013 4:40 PM
*To:* OpenStack Development Mailing List
*Cc:* Taylor, Monty
*Subject:* Re: [openstack-dev] Keystone Split Backend LDAP Hang Problem
That's been a "don't do that" for quite a while, but we might finally
have a solution in havana:
https://blueprints.launchpad.net/keystone/+spec/pagination-backend-support
On Wed, Aug 7, 2013 at 3:56 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis) <[email protected] <mailto:[email protected]>> wrote:
Hello,
I ran into an issue/problem with keystone and it is ok to simply tell
me to "don't do that", but I am wondering how others approach this
problem.
I have the keystone H-2 split backend code connected the HP Enterprise
Directory which is humongous in size. From that directory I have only
one user configured with a project role in keystone. When I performed
the following REST API call:
GET: http://15.253.58.141:35357/v3/users
The keystone server took almost an hour and a half to process my
request before responding with the correct information:
2013-07-28 08:54:24 DEBUG [keystone.common.ldap.core] LDAP bind:
dn=cn=CloudOSKeystoneDev, ou=Applications, o=hp.com <http://hp.com>
2013-07-28 08:54:25 DEBUG [keystone.common.ldap.core] In
get_connection 6 user: cn=CloudOSKeystoneDev, ou=Applications,
o=hp.com <http://hp.com>
2013-07-28 08:54:25 DEBUG [keystone.common.ldap.core] MY query in
_ldap_get_all filter: None, query: (&(objectClass=hpPerson))
2013-07-28 08:54:25 DEBUG [keystone.common.ldap.core] LDAP search:
dn=ou=People,o=hp.com <http://hp.com>, scope=2,
query=(&(objectClass=hpPerson)), attrs=['None', 'userPassword',
'hpStatus', 'mail', 'cn']
2013-07-28 10:20:10 INFO [access] 15.253.57.88 - -
[28/Jul/2013:17:20:10 +0000] "GET http://15.253.58.141:35357/v3/users
HTTP/1.0" 200 87832184
2013-07-28 10:20:25 DEBUG [eventlet.wsgi.server] 15.253.57.88 - -
[28/Jul/2013 10:20:25] "GET /v3/users HTTP/1.1" 200 87832342 5160.268039
REST API response:
{
"user": {
"name": "[email protected] <mailto:[email protected]>",
"links": {
"self": "http://localhost:5000/v3/users/[email protected]";
},
"enabled": "Active",
"domain_id": "default",
"email": "[email protected] <mailto:[email protected]>",
"id": "[email protected] <mailto:[email protected]>"
}
}
After completing my request I found that Keystone was locked up and
required a stop/start service command to get it responding again. How
do other people with ldap backends handle this problem?
Thanks,
Mark
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-Dolph
_______________________________________________
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
