Disable logging in syslog, logging in general, how to implement it?

2,072 views
Skip to first unread message

Strahinja Kustudić

unread,
Feb 21, 2014, 6:13:06 PM2/21/14
to ansible...@googlegroups.com
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? 

Michael DeHaan

unread,
Feb 21, 2014, 6:18:19 PM2/21/14
to ansible...@googlegroups.com
So a few things.

(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.




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6fa0c491-2d5c-4318-b9ce-644c88a97c10%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Brian Coca

unread,
Feb 21, 2014, 6:18:19 PM2/21/14
to ansible...@googlegroups.com
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).


--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

Strahinja Kustudić

unread,
Feb 21, 2014, 7:54:12 PM2/21/14
to ansible...@googlegroups.com
So basically a no_log to work in a play and as a setting in ansible.cfg is fine with you. Sounds good to me :)

Michael DeHaan

unread,
Feb 21, 2014, 8:26:04 PM2/21/14
to ansible...@googlegroups.com
Exactly.

Petros Moisiadis

unread,
Feb 22, 2014, 5:11:06 AM2/22/14
to ansible...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

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?

Walid

unread,
Feb 22, 2014, 7:08:51 AM2/22/14
to ansible...@googlegroups.com
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 ?


Strahinja Kustudić

unread,
Feb 22, 2014, 7:32:46 AM2/22/14
to ansible...@googlegroups.com
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.

Michael DeHaan

unread,
Feb 22, 2014, 8:57:32 AM2/22/14
to ansible...@googlegroups.com
let's not creep scope too much here all at once.

We have a no_log argument and a feature to plumb it up.

What is logged is basically the invocations of the module, so there's nothing really to tweak based on a level yet.


Michael DeHaan

unread,
Feb 22, 2014, 8:58:02 AM2/22/14
to ansible...@googlegroups.com
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.

Petros Moisiadis

unread,
Feb 22, 2014, 9:36:57 AM2/22/14
to ansible...@googlegroups.com
On 02/22/2014 03:57 PM, Michael DeHaan wrote:
let's not creep scope too much here all at once.

We have a no_log argument and a feature to plumb it up.

What is logged is basically the invocations of the module, so there's nothing really to tweak based on a level yet.

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.

Michael DeHaan

unread,
Feb 22, 2014, 10:07:23 AM2/22/14
to ansible...@googlegroups.com
"Don't you think that at some point it would be useful to support different logging levels? Most systems have them."

The no_log directive deals with invocation logging on the remotes only.

There is *MUCH* more data logged on the server.




Adam Morris

unread,
Feb 22, 2014, 1:04:39 PM2/22/14
to ansible...@googlegroups.com


On Saturday, February 22, 2014 7:07:23 AM UTC-8, Michael DeHaan wrote:
"Don't you think that at some point it would be useful to support different logging levels? Most systems have them."

The no_log directive deals with invocation logging on the remotes only.

There is *MUCH* more data logged on the server.



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.

Adam
Reply all
Reply to author
Forward
0 new messages