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.
Mark
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
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)
<mark.m.mil...@hp.com<mailto:mark.m.mil...@hp.com>> 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": "mark.m.mil...@hp.com<mailto:mark.m.mil...@hp.com>",
"links": {
"self": "http://localhost:5000/v3/users/mark.m.mil...@hp.com";
},
"enabled": "Active",
"domain_id": "default",
"email": "mark_m_mil...@hp.com<mailto:mark_m_mil...@hp.com>",
"id": "mark.m.mil...@hp.com<mailto:mark.m.mil...@hp.com>"
}
}
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
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-Dolph
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
