I would like to disable logging of module invocation in syslog, so I wanted to submit a pull request. Than I saw that there are (were) already two pull requests which implemented this change, one of them was rejected, while the other one is still not merged. Because of this and because there are a few gray areas what is the best way to implement this, I would like to discuss it.
In the rejected pull request https://github.com/ansible/ansible/pull/3253 which supports a configuration variable in ansible.cfg syslog_facility to be off’, ‘no’, ‘false’, 'False, but Michael replied to this pull request:
yeah this isn’t how I wanted it implemented actually, it should pass the facility down as “None” and understand that None means to not log, that way we have to do less replacements on the file.
In the second pull request https://github.com/ansible/ansible/pull/5552 a new configuration variable is added to the ansible.cfg called disable_invocation_logging which if set to True disables logging.
The first implementation looks more like what Michael wanted, since syslog_facility already exists, so if we set it to “None”, it should stop logging to it. The problem with this is that we still have systemd logging, which isn’t disabled like this, so what should we do with that? On the other hand the second solution disables logging both for syslog and journal. I would also like to mention that we should probably think about the possibility of logging into a file as a third option.
What do you think would be the best way to implement this? Should we allow to disable logging separately for syslog and for journal, by syslog_facility=None and disable_journal=True (or whatever), or one configuration would be better?
A request was merged to add the keyword no_log: at task level. This should
work for specific tasks, but for a global approach we might need to expand
the scope (as other vars can work global/play/task scope also).
(A) that first ticket is pretty old and I won’t pretend my evaluation of things is going to be constant.
(B)
So we have already added “no_log: True” to a task in 1.5 as a task parameter. Before we release we make sure all of this stuff is well documented, so I’m not sure if it has a page yet. It will soon.
This is a task parameter, so logging on specific tasks can be disabled.
I would be open to pull requests that expose this “up” the stack, provided it’s added to the play as “no_log: True/False” (and is template-able) and also a global in settings.
In addition to a boolean ‘no_log’ option I would suggest another ‘log_level’ option that would control the level of logging at global level (in asinble.cfg), at command-line invocation level (with a --log-level option) and on a per task basis. The precedence of these options can be discussed further but I think it would be reasonable to have: command-line > per task option > ansible.cfg option. Possible levels would be ‘debug’, ‘info’, ‘warning’ and ‘error’ with the default being ‘info’. Modules could be taught to produce logs at specific levels (or at the default level if a specific level is not given). If ‘log_level’ is set to ‘debug’ everything should be logged. If set to ‘info’ it will let all messages go to logs but not those at ‘debug’ level. If set to ‘warning’, it will let messages at ‘warning’ and ‘error’ level, and if set to ‘error’ it will let only messages at ‘error’ level. If logging to syslog, journal, etc., the log message level could be mapped to an appropriate level on each system. What do you think?
I am always wondering why would one choose a negative directive such it can be confusing, no_log : False ==> means log, two negatives? why not make it straightforward and have it part of one directive for logging_levels, none, debug, info…, critical ?
no_log makes sense for a task, since a task logs by default and a task shouldn’t be the one to decide the log level, the module used in the task should do that. I agree that for a configuration setting one directive like log_level works better.
More intensive logging should always take place server side, which is why you have things like callbacks and Tower – you don’t want just the history on that one host, you want to see the overall larger picture.
A no_log argument is pretty straightforward: an on/off switch that can be set per task or globally. So I think it comes naturally that the discussion is moved at talking about logging levels. Don’t you think that at some point it would be useful to support different logging levels? Most systems have them. I can see great usefulness in allowing modules to indicate the importance of what they do and what they find on systems.
Just my two cents… assuming that no_log is a boolean and defaults to false, I don’t find it too confusing to have a no_log: true applied in specific tasks when you want to turn logging off. no_log: false would only be used by people who want to be explicit or thinking that they might want to flip it at some point. The double negative does not cause me any heartache (not that it would matter if it did). If enough people hated it then a log: boolean option would work just as well but you would want to default it to true… and be careful because the name sounds like it could be the name of a module (like debug?) and that could cause confusion.
log level is not something that I would (personally) want set at the module or task level. I would personally think that the modules should know what they want to log and realistically should include a level in the log message (like syslog does) so that all log messages are sent back (saves extra logic in the modules) and they can be filtered by the receiver. But we already have some of that (most maybe) with -vvvv…
In other words. I like the no_log: option but see no reason to be able to modify log levels at anything lower than the reporting level.
