When assigning both prior role and implied role in the implied role chain (that is more than two levels deep) to a given user for a given project, you'll see a rather confusing and misleading error in the Keystone log that looks like this.
Nov 16 11:50:03 keystone <email address hidden>[17003]: ERROR keystone.assignment.core [None req-770cd1c8-b5bd-4b37-b2b3-1e7bc57b8093 None None] Circular reference found role inference rules -
c6025062f9704caba0be20ebd3f7b4f0
First off all, this is not a fatal error as the operation will eventually succeed. We merely log it as *ERROR* without reraising it. See
https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L673
So it shouldn't be an error from operational standpoint. Perhaps we should consider downgrading it to warning instead?
But the bigger problem is how did we even get into this situation to begin with. Shouldn't this situation be prevented at role assignment? i.e. checking for potential circular inference prior to finalizing the assignment.
Steps to reproduce the problem:
1. provision a devstack
2. source devstack/openrc admin admin
3. openstack role add --user admin --project admin member
4. openstack role assignment list --user admin --project admin --effective
5. sudo journalctl (and you'll see the 'Circular reference found role inference rules' error in the logs)
Another alternative would be to create your own implied role chain.
1. provision a devstack
2. source devstack/openrc admin admin
3. openstack role create foo
4. openstack implied role create --implied-role reader foo
5. openstack role create another_foo
6. openstack implied role create --implied_role foo another_foo
7. openstack role add --user demo --project demo foo
8. openstack role add --user demo --project demo another_foo
9. openstack role assignment list --user demo --project demo --effective
10. sudo journalctl (and you'll see the 'Circular reference found role inference rules' error in the logs)
NOTE: this happens when we an implied role chain is more than two levels deep. i.e.
another_foo -> foo -> reader
This was highlighted as a problem (identified) in an unrelated bug. The error was a red-herring there and probably simply an issue with our validation logic.
I'll poke at the code a little more closely here once I get back home. The core issue is in this for loop[0], and it looks like it's possibly mis-detecting the "next role ref" equivalency in the checked_role_ref list.
[0] https:/