[keystone] presence of policy.json breaks Keystone?
This is on a stable Stein Devstack. Problem description: ubuntu@devstack:~$ oslopolicy-sample-generator --namespace keystone
/etc/keystone/policy.json ubuntu@devstack:~$ openstack user list Internal Server Error (HTTP 500)
Note that I did not modify the policy.json file above. It's mere presence is sufficient to cause the problem. When I remove it and restart Keystone, the problem goes away. The Keystone log contains a huge stacktrace with two methods in oslopolicy/_checks.py playing ping-pong with each other until they give up with RuntimeError: maximum recursion depth exceeded. This only happens with Keystone. Nova and Cinder (which also keep policy in code) are fine. This looks like a bug, but I didn't find it in launchpad. Is there a workaround? I would like to use a modified Keystone policy in a training course. Thanks for any feedback. Bernd.
On 9/23/19 10:46 PM, Bernd Bausch wrote:
This is on a stable Stein Devstack. Problem description:
ubuntu@devstack:~$ oslopolicy-sample-generator --namespace keystone
/etc/keystone/policy.json ubuntu@devstack:~$ openstack user list Internal Server Error (HTTP 500)
Note that I did not modify the policy.json file above. It's mere presence is sufficient to cause the problem. When I remove it and restart Keystone, the problem goes away.
The Keystone log contains a huge stacktrace with two methods in oslopolicy/_checks.py playing ping-pong with each other until they give up with RuntimeError: maximum recursion depth exceeded.
This only happens with Keystone. Nova and Cinder (which also keep policy in code) are fine.
This looks like a bug, but I didn't find it in launchpad. Is there a workaround? I would like to use a modified Keystone policy in a training course.
Unfortunately there are two potential bugs that you may be hitting. Fortunately they're both fixed on master. I've proposed backports of the patches to stable/stein. First is bad aliases created when a policy rule is deprecated but the name isn't changed: https://review.opendev.org/#/c/684316 Second is a problem with the deprecation logic that can cause an implicit loop because of how we handle overrides of deprecated policies: https://review.opendev.org/#/c/684314/ I'm guessing you're hitting one of those. This is a relatively new thing because of the migration to use scopes in Keystone, which is why you don't see it in any of the other projects.
Thanks for any feedback.
Bernd.
On 9/24/19 3:30 PM, Ben Nemec wrote:
On 9/23/19 10:46 PM, Bernd Bausch wrote:
This is on a stable Stein Devstack. Problem description:
ubuntu@devstack:~$ oslopolicy-sample-generator --namespace keystone >/etc/keystone/policy.json ubuntu@devstack:~$ openstack user list Internal Server Error (HTTP 500)
Note that I did not modify the policy.json file above. It's mere presence is sufficient to cause the problem. When I remove it and restart Keystone, the problem goes away.
The Keystone log contains a huge stacktrace with two methods in oslopolicy/_checks.py playing ping-pong with each other until they give up with RuntimeError: maximum recursion depth exceeded.
This only happens with Keystone. Nova and Cinder (which also keep policy in code) are fine.
This looks like a bug, but I didn't find it in launchpad. Is there a workaround? I would like to use a modified Keystone policy in a training course.
Unfortunately there are two potential bugs that you may be hitting. Fortunately they're both fixed on master. I've proposed backports of the patches to stable/stein.
First is bad aliases created when a policy rule is deprecated but the name isn't changed: https://review.opendev.org/#/c/684316
Second is a problem with the deprecation logic that can cause an implicit loop because of how we handle overrides of deprecated policies: https://review.opendev.org/#/c/684314/
I'm guessing you're hitting one of those. This is a relatively new thing because of the migration to use scopes in Keystone, which is why you don't see it in any of the other projects.
Hi Ben, Please do backport these patch, they are useful, and the bug is kind of annoying. :) Cheers, Thomas Goirand (zigo)
participants (3)
-
Ben Nemec
-
Bernd Bausch
-
Thomas Goirand