Comment 3 for bug 1742569

I'm not convinced by this as a fix.

By putting this, uncommented, in the sample file we ensure that everyone who uses (a modified version of) the sample policy will get deprecation warnings for the deprecated policies.

I'm surprised if it doesn't result in cycles when using the sample policy, because if the new policy is not specified but the deprecated one is the IIUC it is supposed to fall back to the deprecated one from the file... which points to the new one.

It also assumes that there is a 1:1 mapping between new and deprecated policies. If you use a DeprecatedRule to split an old policy into more granular ones as explicitly documented in https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.html#oslo_policy.policy.DeprecatedRule then you will end up with multiple definitions of the old rule, one of which will presumably win. But there's no way to tell which of the new policies is the correct one to copy the rule from for older releases - and indeed none of them may be correct.

At the very least we need a way to suppress this output.

Perhaps I am misunderstanding the problem, but TBH I would have thought it would be sufficient to add both the new and deprecated policies, commented out, with their default rules. The comments identify the release in which something was deprecated; I think it's fair to require users who are in the process of upgrading from the previous release need to keep any custom policy rules that are about to be deprecated until they have completed the upgrade to the release in which they are actually deprecated.