Closed jnpr-bowen closed 3 years ago
The code change is now in pull request #252
There is a condition that my pull request deals with but the message may not be "the best", looking for comments/suggestions about changing the output message. The situation is if a test executes an RPC for which the the device is not configured, like something IS-IS related and the device is not running IS-IS. The result is that the JSNAPy result structure says one test failed, but there is no 'message' field in the failed results list. In my pull request the message printed is hard coded into jsnapy.py and looks like:
-- Test: get_isis_adjacency_information
Errors for test: ISIS_Status
Test failed without providing message.
The RPC response won't match any xpath and can't be put in the JSNAPy error message as it is just:
<output>IS-IS instance is not running</output>
After showing this test to the customer, they suggested "Test invalid for node." be printed, but I don't know if that will be 100% true. Should the message also say something about checking the RPC response file?
Based on the discussion on #252 , closing this.
Using jsnapy 1.2 to get fields from the updated test_results structure. For my project I have made a change to jsnapy.py that tries to provide an 'operator friendly' output to running of jsnapy tests in Ansible and added a keyword to the junos_jsnapy module that controls whether you get error, or error+info messages from JSNAPy. Below is sample output generated by running a test playbook. Is there an interest for me to make this a pull request to the ansbile-junos-stdlib? 'reporting' is a var in my playbook and sets the value for "callback" on my modified junos_jsnapy module. Callback, if not set, leaves the old callback output, error gives only error messages from test, info gives both error and info messages. The examples below do not show the 'coloring' the callback applies. "Results for:" header is Blue, and error messages are Red, all other text is b/w. "-- Test: " header comes from the rpc/cli that is executed (AKA the 'test_name' key for the list of results for that rpc/cli in the test_results json). "Results for" and "Errors for" all come from 'test_name' key that is inside the test_name list. This is due to something like 'ping' may be executed multiple times for different destinations. Ping will only be a key in the test_results one time, but the list could have unique names for test_name if provided (look at error+info output below).
Running for errors: $ ansible-playbook -i lab_role.inv -l lab-chi-spn02 test_run.pb.yml -e reporting=error
Running for errors+info: $ ansible-playbook -i lab_role.inv -l lab-chi-spn02 test_run.pb.yml -e reporting=info