Open Stack

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.mathews at 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.miller at hp.com<mailto:mark.m.miller at 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.miller at hp.com<mailto:mark.m.miller at hp.com>",
        "links": {
            "self": "http://localhost:5000/v3/users/mark.m.miller@hp.com"
        },
        "enabled": "Active",
        "domain_id": "default",
        "email": "mark_m_miller at hp.com<mailto:mark_m_miller at hp.com>",
        "id": "mark.m.miller at hp.com<mailto:mark.m.miller at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130808/bbbf9a5a/attachment.html>