get_group_project_roles() asks same ldap query for all groups associated with user

[alexius ludeman]

in assignment/core.py:_get_group_project_roles() iterators over all my ldap user groups and calls self._get_metadata(group_id=x['id'], tenant_id=project_ref['id'])

in assignment/backends/ldap.py:_get_metadata() has a parameter group_id but it not used in the function.

this effectively calls ldap for every group with the identical question:
    2013-07-26 21:50:32,026 (keystone.common.ldap.core): DEBUG core search_s LDAP search: dn=cn=groups,dc=bogus,dc=com, scope=1, query=(&(cn=OS_TENANT_NAME)(objectClass=posixGroup)), attrs=['enabled', 'cn', 'businessCategory', 'description']

where OS_TENANT_NAME is shell environment variable.

[Dolph Mathews (dolph)]

I assume the same can be accomplished in a single query to LDAP?

Adam- I believe I saw a patch in review for this... if that's the case, is the commit message missing this bug number?

[Dolph Mathews (dolph)]

Unassigning due to inactivity.

[Pablo Fernando Cargnelutti (pablo-fernando-cargnelutti)]

Just for my clarification. The idea would be to override get_roles_for_user_and_projects in ldap driver so we can do a the roles gattering using a single LDAP query?

[Dolph Mathews (dolph)]

Sort of - get_roles_for_user_and_project(user_id, tenant_id) is a manager method, not a driver method. But loops over the results of a driver call to list_groups_for_user() because the driver method it really needs doesn't actually exist (something to provide _get_group_project_roles() in a single driver call). So, the for loop could be factored out into the base driver class as a *new* method, and then the LDAP, SQL and KVS implementations could override it with much more efficient methods.

[Pablo Fernando Cargnelutti (pablo-fernando-cargnelutti)]

Clear, thanks for the response.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/86025