state_output option being ignored, salt 2018.3.3

[bwesemann-cxp]

Description of Issue/Question

I am attempting to utilize the option "state_output" so that my state.apply commands do not display so much information every time I run them. My understanding is that by setting state_output to options like "changes" should reduce my output, however, I receive the same level of verbosity no matter what I have tried.

Setup

master:/etc/salt$ egrep "^state_output" master
state_output: changes

Steps to Reproduce Issue

master:/etc/salt$ sudo salt admin1 state.apply
admin1:
    ----------
    file_|-/etc/profile.d/history-format.sh_|-/etc/profile.d/history-format.sh_|-managed:
        ----------
        __id__:
            /etc/profile.d/history-format.sh
        __run_num__:
            62
        __sls__:
            security
        changes:
            ----------
        comment:
            File /etc/profile.d/history-format.sh is in the correct state
        duration:
            135.399
        name:
            /etc/profile.d/history-format.sh
        pchanges:
            ----------
        result:
            True
        start_time:
            22:18:33.041584

output is the same when manually specifying --state-output=changes

Versions Report

master:/etc/salt$ sudo salt --versions-report
Salt Version:
           Salt: 2018.3.3

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-1021-aws
         system: Linux
        version: Ubuntu 18.04 bionic

[Ch3LL]

im not able to replicate this. Did you restart the master after adding this configuration change?

also do you see this behavior with all states or just this one?

[bwesemann-cxp]

Hey @Ch3LL, thanks for the response.

Indeed I do restart after making configuration changes, and this behavior is seen on all state files.

I think I managed to identify what was causing the issue, in my configuration file output: nested was set. When I commented that option, I received the expected output from the state_output option. It seems that option was overwriting state_output as well as cli_summary. Is this intended behavior?

[Ch3LL]

glancing at teh code here: https://github.com/saltstack/salt/blob/v2018.3.3/salt/output/__init__.py#L142

it looks like it would grab that option there,but i think this still would be considered a bug as state_output and output are different and should work together.

[Reiner030]

Same problem for 2019.2.0 in test mode; perhaps it is wrong fixed already (is/was working for me till 2018.3.4) ?

Independent of my default usage of changes or also tested mixed, terse, changes-id, mixed-id, terse-id setting of cli parameter with --state-output=value or as configuration setting in /etc/salt/minion which I tested as preparation from Changelog I got always only in testing mode the wrong output.

This example is from a fresh 2019.2.0 only instance with an additional empty line for showing the bug with a trivial state:

root@vagrant-dev-3218:~# salt-call state.apply hosting.hosts test=True --state-output=changes
local:
----------
          ID: /etc/hosts
    Function: file.managed
      Result: None
     Comment: The file /etc/hosts is set to be changed
     Started: 16:56:34.002961
    Duration: 496.122 ms
     Changes:   

Summary for local
------------
Succeeded: 1 (unchanged=1)
Failed:    0
------------
Total states run:     1
Total run time: 496.122 ms
root@vagrant-dev-3218:~# salt-call state.apply hosting.hosts --state-output=changes
local:
----------
          ID: /etc/hosts
    Function: file.managed
      Result: True
     Comment: File /etc/hosts updated
     Started: 16:56:46.076423
    Duration: 484.033 ms
     Changes:   
              ----------
              diff:
                  --- 
                  +++ 
                  @@ -5,7 +5,6 @@
                   # IPv4 loopback
                   127.0.0.1	localhost
                   127.0.1.1	vagrant-dev-3218
                  -
                   
                   # IPv6 loopback
                   ::1		localhost ip6-localhost ip6-loopback vagrant-dev-3218.<domain> vagrant-dev-3218

Summary for local
------------
Succeeded: 1 (changed=1)
Failed:    0
------------
Total states run:     1
Total run time: 484.033 ms

It's always amazing how untested even newly announced Saltstack features are...

[Ch3LL]

@Reiner030 this issue is related to using both output: nested and state_output: changes together. Do you have both output and state_output set? If not can you please open a new issue with all the details of your issue for this version.

It's always amazing how untested even newly announced Saltstack features are...

Going forward our main focus within salt is stability. We are now requiring all bug fixes and features to require test coverage, whereas previously this was not a requirement. We also will not merge a PR into the repo unless all tests have passed, even if the test failure is not related to the change. In the past we would merge a PR if the test failure was not related. This will ensure our test suite is consistently stable and that should mirror into the stability of salt's code base. Furthermore our goal is to run all OSs we currently run on branch tests against PRs. This will help us to catch things sooner than later. All of these changes will help ensure that in our future releases there will be more stability. Hopefully that helps ease some of your concerns for the future.

[dawidmalina]

@Ch3LL I have exactly the same issue with output for highstate but in my case it started after upgrade from 2018.3.3 to 2019.2.0.

So currently when I execute:

sudo salt-call state.apply

I will see output similar to this:

    sysctl_|-net.netfilter.nf_conntrack_max_|-net.netfilter.nf_conntrack_max_|-present:
        ----------
        __id__:
            net.netfilter.nf_conntrack_max
        __run_num__:
            123
        __sls__:
            system.optimize.sysctl
        changes:
            ----------
        comment:
            Sysctl value net.netfilter.nf_conntrack_max = 1048576 is already set
        duration:
            7.698
        name:
            net.netfilter.nf_conntrack_max
        result:
            True
        start_time:
            11:16:57.063096

When I will apply single state:

sudo salt-call state.apply hardening.users

I will see this output:

local:

Summary for local
-------------
Succeeded: 33
Failed:     0
-------------
Total states run:     33
Total run time:   94.386 ms

I'm not configuring output and my custom output configuration looks like this:

state_verbose: false
state_output: mixed_id

[Ch3LL]

im having a hard time replicating your test case @dawidmalina

[root@1ef744603129 /]# salt-call --local state.apply 
local:
  Name: echo test - Function: cmd.run - Result: Changed Started: - 17:58:03.018480 Duration: 523.13 ms

Summary for local
------------
Succeeded: 1 (changed=1)
Failed:    0
------------
Total states run:     1
Total run time: 523.130 ms
[root@1ef744603129 /]# salt --version
salt 2019.2.0 (Fluorine)

I know that we made some fixes related to the outputer that will be coming out on 2019.2.1. Any chance you can give the 2019.2.1 branch a try?

[dawidmalina]

Thx @Ch3LL I will give it a try and I will test new branch. In addition I will try to prepare some test environment in docker.

[dawidmalina]

@Ch3LL sorry for such a long delay. During test environment preparation we found issue on our side (better don't ask what was it). So I can confirm no problems on saltstack side.

[stale]

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.

[stale]

Thank you for updating this issue. It is no longer marked as stale.