Comment 1 for bug 910456

I had a chance to dive a little deeper into the code:

  in the following file: keystone /keystone/backends/sqlalchemy/api/tenant.py from get_role_assignment lines 355 - 359

        for result in results:
            if hasattr(api.USER, 'uid_to_id'):
                result.user_id = api.USER.id_to_uid(result.user_id)
            if hasattr(api.TENANT, 'uid_to_id'):
                result.tenant_id = api.TENANT.id_to_uid(result.tenant_id)

This iterates through all of the matching rows and actually *modifies* those rows in a way that breaks them (it replaces the ids with the uids)

It seems inappropriate for a method called get_role_assignment to be updating the role table

All of this code was added as a single commit:

d1d3df0465f6ef1b14ed71eeed84d92c9fe6f256 which is by Ziad Sawalha

It looks like this code was added as a part of some migration from ids to uids as keys

As of keystone-manage 2012.1-dev, it looks like the schema of user_roles has not been updated to use uids instead of ids as the foreign keys

sqlite> .schema user_roles
CREATE TABLE user_roles (
 id INTEGER NOT NULL,
 user_id INTEGER,
 role_id INTEGER,
 tenant_id INTEGER,
 PRIMARY KEY (id),
 UNIQUE (user_id, role_id, tenant_id),
 FOREIGN KEY(role_id) REFERENCES roles (id),
 FOREIGN KEY(tenant_id) REFERENCES tenants (id),
 FOREIGN KEY(user_id) REFERENCES users (id)

doing a quick scan of the migration versions (from master), I can see that user_role has not been updated since the initial migration, so I doubt this has been fixed.

# /keystone/backends/sqlalchemy/migrate_repo/versions
grep user_role *