With the icehouse code base, if you call keystone v2's keystone.tenant.list_users(<tenant_id>) it returns each user * the number of roles the user has in the project.
My assignment table for my test server looks like this for one specific project_id:
mysql> select * from assignment where target_id='0f031cca55704f87af9630d939c1ebd3'\G
*************************** 1. row ***************************
type: UserProject
actor_id: 665cae4478fb47a1ab21eecf95ea200c
target_id: 0f031cca55704f87af9630d939c1ebd3
role_id: dc6dbe0f687d4afb8f2634fb2a3a61c2
inherited: 0
*************************** 2. row ***************************
type: UserProject
actor_id: 665cae4478fb47a1ab21eecf95ea200c
target_id: 0f031cca55704f87af9630d939c1ebd3
role_id: bd089cb8a31c47af9aff36e40fe8e99e
inherited: 0
*************************** 3. row ***************************
type: UserProject
actor_id: 665cae4478fb47a1ab21eecf95ea200c
target_id: 0f031cca55704f87af9630d939c1ebd3
role_id: 9ee0b22736dd4fc480432929dfa1e899
inherited: 0
*************************** 4. row ***************************
type: UserProject
actor_id: 665cae4478fb47a1ab21eecf95ea200c
target_id: 0f031cca55704f87af9630d939c1ebd3
role_id: 9fe2ff9ee4384b1894a90878d3e92bab
inherited: 0
*************************** 5. row ***************************
type: UserProject
actor_id: 665cae4478fb47a1ab21eecf95ea200c
target_id: 0f031cca55704f87af9630d939c1ebd3
role_id: b804871ba2c543fdbc0e20bc0ebcd658
inherited: 0
5 rows in set (0.01 sec)
So user '665cae4478fb47a1ab21eecf95ea200c' has 5 roles in project '0f031cca55704f87af9630d939c1ebd3'. With a keystone client connection to v2.0, I get the same user returned 5 times:
>tenants.list_users('0f031cca55704f87af9630d939c1ebd3')
[<User {u'username': u'ctina', u'name': u'ctina', u'enabled': True, u'tenantId': u'0f031cca55704f87af9630d939c1ebd3', u'id': u'665cae4478fb47a1ab21eecf95ea200c', u'email': None}>, <User {u'username': u'ctina', u'name': u'ctina', u'enabled': True, u'tenantId': u'0f031cca55704f87af9630d939c1ebd3', u'id': u'665cae4478fb47a1ab21eecf95ea200c', u'email': None}>, <User {u'username': u'ctina', u'name': u'ctina', u'enabled': True, u'tenantId': u'0f031cca55704f87af9630d939c1ebd3', u'id': u'665cae4478fb47a1ab21eecf95ea200c', u'email': None}>, <User {u'username': u'ctina', u'name': u'ctina', u'enabled': True, u'tenantId': u'0f031cca55704f87af9630d939c1ebd3', u'id': u'665cae4478fb47a1ab21eecf95ea200c', u'email': None}>, <User {u'username': u'ctina', u'name': u'ctina', u'enabled': True, u'tenantId': u'0f031cca55704f87af9630d939c1ebd3', u'id': u'665cae4478fb47a1ab21eecf95ea200c', u'email': None}>]
The Havana code calls the following:
def list_user_ids_for_project(self, tenant_id):
session = self.get_session()
self.get_project(tenant_id)
query = session.query(UserProjectGrant)
query = query.filter(UserProjectGrant.project_id ==
tenant_id)
project_refs = query.all()
return [project_ref.user_id for project_ref in project_refs]
class UserProjectGrant(sql.ModelBase, BaseGrant):
__tablename__ = 'user_project_metadata'
user_id = sql.Column(sql.String(64), primary_key=True)
project_id = sql.Column(sql.String(64), sql.ForeignKey('project.id'),
primary_key=True)
data = sql.Column(sql.JsonBlob())
The user_project_metadata table has the roles listed as a dictionary inside of the 'data' column, so each user has only one entry. The Icehouse code calls the same list_user_ids_for_project but it uses the assignment table which has one entry for each user/project/role combination, leading to a user to potentially have multiple entries per project.
This seems to be a pretty big regression in v2 API behavior.