This seems like something we should be able to fix and backport to Ocata
since it has an impact on performance.
** Tags added: performance
** Also affects: keystone/newton
Importance: Undecided
Status: New
** Also affects: keystone/ocata
Importance: Undecided
Status: New
** Changed in: keystone/newton
Status: New => Confirmed
** Changed in: keystone/ocata
Status: New => Confirmed
** Changed in: keystone
Status: New => Confirmed
** Changed in: keystone/newton
Status: Confirmed => Won't Fix
** Changed in: keystone
Importance: Undecided => Medium
** Changed in: keystone/ocata
Importance: Undecided => Medium
** Tags added: ocata-backport-potential
** Changed in: keystone
Milestone: None => pike-3
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1700852
Title:
Slow listing projects for user with many role assignments
Status in OpenStack Identity (keystone):
Confirmed
Status in OpenStack Identity (keystone) newton series:
Won't Fix
Status in OpenStack Identity (keystone) ocata series:
Confirmed
Bug description:
With a large number of role assignments (e.g 500) it becomes very slow
to list the projects a user has access to (via /users/<id>/projects).
I'm seeing times of around 4 seconds versus 0.1 for a user with a
couple of assignments.
Instrumenting list_projects_for_user
(https://github.com/openstack/keystone/blob/stable/newton/keystone/assignment/core.py#L268),
where each number is the time elapsed since the start of
list_projects_for_user, I get:
list_projects_for_user 3.998 role_assignments
list_projects_for_user 3.999 project_ids
list_projects_for_user 4.105 list_projects
The time is spent on the call made to list_role_assignments on line
269 which in turns calls _list_effective_role_assignments at
https://github.com/openstack/keystone/blob/stable/newton/keystone/assignment/core.py#L986.
Listing role assignments for a user directly (with GET
/role_assignments?user.id=<id>) is very fast, which is further
indication that something in the effective role processing is the
cause. I haven't yet timed the internal of
_list_effective_role_assignments.
Running keystone newton (though I believe this would apply to master) with
users in LDAP but roles and projects managed by keystone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1700852/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
