* now module errors clearly state msg=MODULE FAILURE
* module's stdout and stderr go into module_stdout and module_stderr keys
which only appear during parsing failure
* invocation module_args are deleted from results provided by action
plugin as errors can keep us from overwriting and then disclosing info that
was meant to be kept hidden due to no_log
* fixed invocation module_args set by basic.py as it was creating different
keys as the invocation in action plugin base.
* results now merge
It is natural that an argument_spec with choises=BOOLEAN accepts
boolean literal (True, False) though the current implementation
allows only string or int.
(Reminder: cannot use six here, module_utils get shipped to remote
machines that may not have six installed -- besides six doens't support
Python 2.4.)
* allow global no_log setting, no need to set at play or task level, but can be overriden by them
* allow turning off syslog only on task execution from target host (manage_syslog), overlaps with no_log functionality
* created log function for task modules to use, now we can remove all syslog references, will use systemd journal if present
* added debug flag to modules, so they can make it call new log function conditionally
* added debug logging in module's run_command
Make the code compatible with Pythons 2.4 through 3.5 by using
sys.exc_info()[1] instead.
This is necessary but not sufficient for Python 3 compatibility.
If you look at the meaning of the different syslog levels, NOTICE means that the event may need someone to look at it. Whereas INFO is pure informational.
Since module invocations are in fact requested (deliberate) actions, they shouldn't need any additional post-processing, and therefore should not be logged as NOTICE.
This may seem like hairsplitting, but correctly categorizing system events helps weeding through the noise downhill.
According to Wikipedia: https://en.wikipedia.org/wiki/Syslog
5 Notice notice Events that are unusual but not error conditions .
6 Informational info Normal operational messages -no action required. Example an application has started, paused or ended successfully.
There is a common pattern in modules where some parameters are required
only if another parameter is present AND set to a particular value. For
instance, if a cloud server state is "present" it's important to
indicate the image to be used, but if it's "absent", the image that was
used to launch it is not necessary. Provide a check that takes as an
input a list of 3-element tuples containing parameter to depend on, the
value it should be set to, and a list of parameters which are required
if the required parameter is set to the required value.
