"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. On Sat, Feb 22, 2014 at 9:36 AM, Petros Moisiadis <[email protected]> wrote: > 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. > > > On Sat, Feb 22, 2014 at 7:32 AM, Strahinja Kustudić <[email protected] > > wrote: > >> 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. >> >> >> On Saturday, February 22, 2014 1:08:51 PM UTC+1, Walid Shaari wrote: >> >>> 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 ? >>> >>> >>> On 22 February 2014 02:18, Michael DeHaan <[email protected]> wrote: >>> >>>> 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. >>>> >>>> >>>> https://github.com/ansible/ansible/blob/fcb760c36cc070bb23f1357c9bbedd66065d19c0/lib/ansible/playbook/task.py >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> On Fri, Feb 21, 2014 at 6:13 PM, Strahinja Kustudić < >>>> [email protected]> wrote: >>>> >>>>> 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? >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> >>>>> 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. >>>>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/CAEVJ8QNros8h%3D_hkFCdctbNtKH%3DRL%2BCrJC-ZQ8H7M%3Dg03Jk%2B2w%40mail.gmail.com. >>>> >>>> >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/7c585762-9780-4f3f-88db-1881fb71751c%40googlegroups.com. >> >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAEVJ8QOHPj%3Dpo3c85M3WoUrkE2UQbaNfYO2bEXXpPK1xP_hOAg%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/5308B609.3050107%40yahoo.gr > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEVJ8QOGDMTAFyF9wsyjQ4LyP6Zk1MoPA4-o2SyaLoEOO8K5Ew%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
