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.


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/fcb760c36cc070bb23f1357c9bbedd
>>> 66065d19c0/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/5552a 
>>>> 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.

Reply via email to