Related: From the discussion about "no remote logging" yesterday, it
almost seems as if the command module is the only one we wouldn't want to
log. In which case, might the no logging use case be handled in exactly the
same way?
Sounds reasonable to me. However, I do think it would be useful to
have the concept of log levels for all modules. I was going to
propose:
- hosts: all
log: info
- name: update-something
action: command ....
log: debug
Log levels could be something like warn, info, debug -- this way log
files could be grepped, and certain log levels (debug) could be
avoided from logging entirely. info would be default. log level could
be set on the play level or on the action level.
For conveying the log level to the module, could we not just have
extra k/v pairs, such as _loglevel=info, added to the args file. This
would allow flexibility in passing other 'standard' args -- for
example, args common to the entire playbook.Of course, we could use
the setup vars and let the module read those...
Matthew
Just to make sure we’re not confusing two things here:
-
REMOTE LOGGING * – whether or not the module should log on the managed server the arguments that it was invoked with. We don’t do this. Right now we log everything, and the discussion is about being able to turn this off, selectively, so that commands that have sensitive information in them, are not logged with the arguments used to run them in /var/log/messages.
-
MODULE STDERR DEBUG * – whether the standard error from the module should be logged or not. We already do this with -D. I’m in favor of just renaming this to “–verbose” and will probably do this very soon, and we can also be more verbose in other places when we see this flag.
I generally would like to keep syntax down to a minimum, so I don’t think task selectable control over stderr output should be something we do. Generally most tools that have a --verbose options.
I also feel that logging on the remote what happens is a very very good thing to do, so I don’t think we should encourage people turning that off. So by default I would hope each module is written to log what arguments it executes. Having any sort of facility o tell the module how much it should write to /var/log/messages shouldn’t be necessary – it shouldn’t log anything other than the arguments it was invoked with, and the rest of the logging – the detailed bits – can just bubble up back to the server over standard error.
Sure, lots of people want to do things differently, but I want to stick to my guns when creating the project here. Ansible is not supposed to be the uber-flexibile configuration management system with lots of features… it’s supposed to be pretty stripped down and simple. For that reason, not offering choices is sometimes going to be the best route. This is going to mean saying no to some features when we believe sensible defaults are good enough.
Thus, I think this is the way we’re going to do module logging on the managed machines
- not use the remote SSH execution of /usr/bin/logger like we do now at all (faster)
- each module always logs what it is invoked with using /usr/bin/logger at start EXCEPT
- if that module is the command module and it gets a stealth=yes # or better name
- each module is encouraged to use std err to include debug information to the level it finds relevant, but should
generally err on being concise and sharing only relevant info.
- The existing -D gets renamed -v/–verbose.
- no new playbook syntax for any of the above.
–Michael