Closed mhrivnak closed 5 years ago
@jimi-c Could you list out what the valuable pieces for every event might be? This would help us determine what useful info to expose is.
@shawn-hurley / @mhrivnak the doc for what runner sends back is here: https://ansible-runner.readthedocs.io/en/latest/intro.html#runner-artifact-job-events-host-and-playbook-events
It looks like the best course of action would be to print the stdout
field from the data blob if that key exists, otherwise print the event_data (or the entire blob, if people prefer). Within event data, as I said in chat, there are pretty much only 2-3 fields that stay static: rc
, changed
and failed
. The failed
key is not always set in the data, but if it is there should also be a corresponding msg
field (though that is not strictly enforced). You could look for that though, if you wanted to do some special logging to highlight failures or to trigger other events.
Generally if there is anything in the event{} data structure then you'll have a stdout
entry. If you're needing to display some content then you can pretty well rely on there being something in there... otherwise you can just throw away and not display any data.
This is the code Tower relies on to drive its own display.
After https://github.com/water-hole/ansible-operator/pull/42, log output consists of a ton a JSON, which is the raw representation of ansible events. It would be more useful to pull out the valuable pieces and log them in a human-readable way.
Here's an example log statement. I think it's actually getting truncated.