saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
https://repo.saltproject.io/
Apache License 2.0
14.14k stars 5.47k forks source link

RunnerClient#cmd does not take an arg 'print_event', and bloats logs #36171

Closed flowstate closed 6 years ago

flowstate commented 8 years ago

Description of Issue/Question

Despite what the docs say, RunnerClient#cmd does not take a print_event argument, and will seemingly always print the full output to the screen. This leads to very bloated logs. Please let me know if I have missed something, or any kind of workaround I can utilize to stop this output from going to my logs.

Thanks, team!

Versions Report

All relevant machines are on 2016.03.3

Ch3LL commented 8 years ago

@flowstate from what I can tell it looks like print_event=False will not show the formated output as shown below:

>>> runner.cmd('test.arg', ['testarg'], print_event=True)
args:
    - testarg
kwargs:
    ----------
{'args': ('testarg',), 'kwargs': {}}
>>> runner.cmd('test.arg', ['testarg'], print_event=False)
{'args': ('testarg',), 'kwargs': {}}

This seems to be working as expected as far as I can see. Are you looking to git rid of the return as well?

flowstate commented 8 years ago

ohhhhh, now I know what the issue is. If you don’t provide args (for instance, I’m using an untargeted call to ‘cache.grains’), then try to pass print_event, it freaks out. I’m not at my computer, but will edit with repro steps later.

Thanks!

On Fri, Sep 9, 2016 at 12:27 PM, Megan Wilhite notifications@github.com wrote:

@flowstate https://github.com/flowstate from what I can tell it looks like print_event=False will not show the formated output as shown below:

runner.cmd('test.arg', ['testarg'], print_event=True) args:

  • testarg kwargs:

    {'args': ('testarg',), 'kwargs': {}} runner.cmd('test.arg', ['testarg'], print_event=False) {'args': ('testarg',), 'kwargs': {}}

Are you looking to git rid of the return as well?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/saltstack/salt/issues/36171#issuecomment-245981628, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYEMLcoC9Vwp7c4EGgF_EXSa3cgm2HLks5qoZcRgaJpZM4J4asH .

flowstate commented 8 years ago

Okay, so I'm still having this issue. I'm on 2016.03.3, and running in the repl, I get the following:

>>> runner.cmd('cache.grains', [], print_event=False, kwarg={"outputter": "json"})['data']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cmd() got an unexpected keyword argument 'print_event'
>>> result = runner.cmd('cache.grains', [], kwarg={"outputter": "json"}, print_event=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cmd() got an unexpected keyword argument 'print_event'
Ch3LL commented 8 years ago

Hmm I'm not seeing that same stack trace:

>>> runner.cmd('cache.grains', [], print_event=True, kwarg={"outputter": "json"})['data']
{}
{}
>>> runner.cmd('cache.grains', [], print_event=False, kwarg={"outputter": "json"})['data']
{}

This is on 2016.3.3, which I believe is your same version even though you pasted 2016.03.3? Is that correct is that the version you are running?

wolfpackmars2 commented 8 years ago

@flowstate Do you have print_event defined somewhere else? The error being returned indicates that the print_event variable isn't being interpreted properly. Is there another library loaded which defines print_event? What is the output of "type(print_event)" ?

The error doesn't seem to be with whether print_event is working or not with runner.cmd -- runner.cmd is generating an error because it doesn't understand print_event as it has been passed. Reviewing the source code and your code snippet would indicate you should not be receiving the error you are seeing. Only other thing I can think of is a quirk with your version of Python...

What happens if you just pass True (as a positional argument) instead of including print_event= (keyword argument). Note that in the code, print_event appears after kwargs in the definition. Try: >>> runner.cmd('cache.grains', None, None, {"outputter": "json"}, False)['data']

Where False is the positional argument for print_event

flowstate commented 8 years ago

Sorry for long delay in response, was quite ill for a few weeks. I’ll try to re-contextualize myself and edit this response with my actual response to your latest suggestion.

On Tue, Sep 27, 2016 at 5:42 PM, Steve Groesz notifications@github.com wrote:

Do you have print_event defined somewhere else? The error being returned indicates that the print_event variable isn't being interpreted properly. Is there another library loaded which defines print_event? What is the output of "type(print_event)" ?

The error doesn't seem to be with whether print_event is working or not with runner.cmd -- runner.cmd is generating an error because it doesn't understand print_event as it has been passed. Reviewing the source code and your code snippet would indicate you should not be receiving the error you are seeing. Only other thing I can think of is a quirk with your version of Python...

What happens if you just pass True (as a positional argument) instead of including print_event= (keyword argument). Note that in the code, print_event appears after kwargs in the definition. Try:

runner.cmd('cache.grains', None, None, {"outputter": "json"}, False)['data']

Where False is the positional argument for print_event

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/saltstack/salt/issues/36171#issuecomment-250020574, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYEMMuzXE0KXaaCxmyCkdwtYxYhfkqVks5quZvxgaJpZM4J4asH .

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.