On 08/08/2013 01:20 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
Adam,
I want to thank for your responses as I am coming up to speed. If I
don't get yanked off to fill some other project holes, Keystone
knowledge and support will become my full time job here at HP.
My pleasure. The more you know, the more you can field these questions
for me.
Mark
*From:*Adam Young [mailto:[email protected]]
*Sent:* Wednesday, August 07, 2013 6:55 PM
*To:* [email protected]
*Subject:* Re: [openstack-dev] Keystone Split Backend LDAP Hang Problem
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] <mailto:[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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
