There were several problems with keystone-manage mapping_engine
* It aborts with a backtrace because of wrong number of arguments
passed to the RuleProcessor, it was missing the mapping_id
parameter.
* Error messages related to input data were cryptic and inprecise.
* The --engine-debug option did not work.
A fake mapping_id is now generated and passed to the RuleProcessor.
If there was invalid data passed it was nearly impossible to determine
what was causing the error, the command takes 2 input files, but which
file contained the error? At what line? Why? For example I was
consistently getting this error:
Error while parsing line: '{': need more than 1 value to unpack
and had no idea of what was wrong, the JSON looked valid to me. Turns
out the assertion file is not formatted as JSON (yes this is
documented in the help message but given the rules are JSON formatted
and the RuleProcessor expects a dict for the assertion_data it's
reasonsable to assume the data in the assertion file is formatted as a
JSON object).
The documentation in mapping_combinations.rst added a note in the
section suggesting the use of the keystone-manage mapping_engine
tester alerting the reader to the expected file formats.
The MappingEngineTester class was refactored slighly to allow each
method to know what file it was operating on and emit error messages
that identify the file. The error message in addition to the pathname
now includes the offending line number as well. As a bonus it doesn't
fail if there is a blank line. The error message now looks like this:
assertion file input.txt at line 4 expected 'key: value' but found 'foo' see help for file format
The mapping_engine.LOG.logger level is now explictily set to DEBUG
when --engine-debug is passed instead of (mistakenly assuming it
defaulted to DEBUG) otherwise it's set to WARN.
Closes-Bug: 1655182
Signed-off-by: John Dennis <jdennis@redhat.com>
Change-Id: I2dea0f38b127ec185b79bfe06dd6a212da75cbca
(cherry picked from commit f2d0f8c9ab)
8726573940