This is actually a bug in the role assignment API. When asking keystone for a list of role assignments for a specific role (GET /v3/role_assignments?role.id={role_id}), it won't prune system role assignments that don't match the role in question. This was causing a problem because we have a notification call back system that attempts to remove assignments before a role is deleted [0]. When the role assignment API goes to ask for all role assignments for a specific role, it doesn't filter out the system role assignments [1]. This was problematic because it was returning a system role assignment for the admin user, which resulted in a false revocation event getting persisted. As soon as tempest cleaned up the roles for a test class, a revocation event would be stored for the admin user and prevent them from cleaning up user, etc...
This is actually a bug in the role assignment API. When asking keystone for a list of role assignments for a specific role (GET /v3/role_ assignments? role.id= {role_id} ), it won't prune system role assignments that don't match the role in question. This was causing a problem because we have a notification call back system that attempts to remove assignments before a role is deleted [0]. When the role assignment API goes to ask for all role assignments for a specific role, it doesn't filter out the system role assignments [1]. This was problematic because it was returning a system role assignment for the admin user, which resulted in a false revocation event getting persisted. As soon as tempest cleaned up the roles for a test class, a revocation event would be stored for the admin user and prevent them from cleaning up user, etc...
[0] https:/ /github. com/openstack/ keystone/ blob/602a2b30a3 c9cb250d06b2e5b 70f961cb5e2cecc /keystone/ assignment/ core.py# L1332 /github. com/openstack/ keystone/ blob/602a2b30a3 c9cb250d06b2e5b 70f961cb5e2cecc /keystone/ assignment/ core.py# L1042
[1] https:/