Comment 3 for bug 1803233

I'm aware of the above patch, it was from my co-worker :-)

The --is-admin doesn't even make sense if the tool accepts unaltered credential data (what an unfortunate name because it's not credentials, rather it's auth context).

Anyway, I have a patch almost ready to go, just need to update the unit test.

As I tried to fix the original problem I kept running into other issues and finally decided to forget about backward compatibility (which I don't think you can ever have with the way the credential data worked) and focus instead on making the tool as useful as possible, which to me means behaving as close as possible to the way project use oslo.policy in their project.

I've also patch oslo.policy to log the credential and target data and it looks like this patch will merge as soon as gate issues are addressed, the change is: https://review.openstack.org/#/c/619260/

My olslopolicy-checker re-write adds the following features:

* Accepts raw credential data (along with the patch for target data noted above it now takes the same data)

* Fully integrated with oslo.config. This mean you can use exactly the same policy config as do actual OpenStack projects use via config files -OR- via command line options.

* Uses oslo.config for the tools argument parsing.

* Instantiates and uses an Enforcer object just like OpenStack projects use instead of the anonymous generic Object hack the checker previously used. It's important we emulate the policy behavior by using the same Python classes.

* Uses the same enforcement call (Enforcer.enforce()) that projects use instead of reaching inside the policy object and invoking rules directly.

* Configures logging and connects the logging output to either the console or a file. You can also set the logging level. BTW, I discovered it was very useful to see log messages because oslo.policy can detect problems in rules (e.g. cycles) and if logging is not connected as was previously the case you never see these vital messages.

* Allows an arbitrary number of individual rules to be checked (it used to be 1 or all)

* Keeps a count (and lists) the rules checked, successful rules, rules with failures, undefined rules (e.g. you specify a rule on the command line but it's not in the policy), and the rules which generated an exception.

* Captures the exception information for any rule that generated an exception.

* Provides meaningful shell exit status values so the tool can be used in automated testing.