Open Stack

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:ayoung at redhat.com]
> *Sent:* Wednesday, August 07, 2013 6:55 PM
> *To:* openstack-dev at lists.openstack.org
> *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: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
>
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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