Open Stack

 ---- On Tue, 19 Jan 2021 17:25:46 -0600 Thomas Goirand <zigo at debian.org> wrote ----
 > On 1/19/21 9:04 PM, Ben Nemec wrote:
 > > There was also a security concern with potentially having multiple
 > > policy files and it not being clear which was in use. If someone
 > > converted their JSON policy to YAML, but left the JSON one in place, it
 > > could result in oslo.policy using the wrong one (or not the one they
 > > expect). We decided it was better for each project to make a clean
 > > switchover, which allows for things like upgrade checks that oslo.policy
 > > couldn't have itself, than to try to handle it all in oslo.policy.
 > 
 > IMO, that's a downstream distro thing.
 > 
 > What I did in Debian (and for Victoria already) was having the postinst
 > of each package to rename any existing policy.json into a disabled
 > version. Here's an example with Cinder:
 > 
 > if [ -r /etc/cinder/policy.json ] ; then
 >     mv /etc/cinder/policy.json /etc/cinder/disabled.policy.json.old
 > fi
 > 
 > and then package the yaml file as (example from Nova):
 > /etc/nova/policy.d/00_default_policy.yaml
 > 
 > and then setting-up this:
 > policy_dirs = /etc/nova/policy.d
 > 
 > The reason I'm doing this way, is that I'm expecting upstream to
 > generate a commented-only yaml file, and final users to drop non-default
 > supplementary files without touching the package default file.
 > 
 > So, someone upgrading to Victoria with a non-default policy.json will
 > see its manual tweaks go away, but not completely gone (ie: recoverable
 > from disabled.policy.json.old).
 > 
 > Does this seem to be a correct approach?
 > 

We have two types of default meaning in policy things. 1. default value of config option 'policy_file' which
we are changing from 'policy.json' -> 'policy.yaml'  and has custom policy rule 2. default value of policy rule
which can be in default policy file or non-default (means keeping all the default value of policy rule in the file ).

I hope with 'default' '00_default_policy.yaml' you mean the former one. If so then instead of keeping JSON
the version also best approach is just using the 'oslopolicy-convert-json-to-yaml' tool to convert it to YAML
format in a backward-compatible way. Newly generated YAML file will keep all the custom rule as it is
and comment-out the default rule.

Let me describe the recommended way for the different scenario:

Scenario1: If you do not have any custom rule in the policy file:
-------------
Recommendation (Very strong): Do not use any file, just remove it and let policy-in-code 
serve the purpose.  OpenStack does not need a policy file as mandatory and if there is no file
present or passed in the config option then it works fine with policy-in-code.

Having a policy file with all default rules (uncommented) can cause any issue and this was the
the reason why Debian packaging broke with Nova's new policy in the Ussuri release.

Scenario2: If you have a policy file with custom rules and in JSON format.
-------------
Recommendation: This is the use case we need to fix and this migration is all about. 
Use the 'oslopolicy-convert-json-to-yaml' tool to convert it to YAML format in a backward-compatible way
Or convert it manually but do not keep the old JSON format file in a configured location otherwise Oslo policy
will pick that if it finds both JSON and YAML formatted file. Just remove the old JSON file as
the same level of permission is present in the converted YAML file.

Scenario3: If you have a policy file with custom rules and in YAML format.
-------------
This is all good and no work needed for this. 

[1] https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html

-gmann

 > Cheers,
 > 
 > Thomas Goirand (zigo)
 > 
 >