Comment 2 for bug 1875418

We discussed this on IRC, there is no clear way to differentiate whether re-generated policy file is 1. A way to move to new defaults or 2. expecting the old defaults also work with new defaults.

We definitely need more documents on re-generated of policy file or usage if policy file when the operator still want to use policy defaults. Basically this bug: https://bugs.launchpad.net/oslo.policy/+bug/1853170

What happened here:

During policy new defaults work, old defaults are kept supported as a deprecated rule along with new defaults. For deployment relying on policy defaults, it will keep working because of old defaults are still supported as a deprecated rule. If the deployment has overridden the policy rule then defaults are not into picture and token are checked as per the overriden rule value.

In this case, policy.json is re-generated with 'oslopolicy-sample-generator' which does not include the deprecated rule in the generated file. This means rule is overridden with the new-default value ("system_admin_api": "role:admin and system_scope:all") only. Policy checks the existing token with these new values in policy.json and fail. This is the exact same way when the operator wants to switch to new defaults by overriding the rule with new defaults in policy.json so that deprecated old rule gets disappear (though we introduced a new way to achieve the new defaults behaviour by enabling a flag 'oslo_policy.enforce_new_defaults' in Ussuri).

Ont thing we can do is to mention this in release notes and expect operators to either not override the rule they want to reply on defaults or update their token to work as per overriden value.

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-04-27.log.html#t2020-04-27T13:46:37