minion salt-call output not very helpful since change..

[mlebel]

Hello, I wasn't able to find another post about this, so i apologize if there is one and i missed it..

Lately, the output of the salt-call command on the minion looks something like this (Colourless):

service_|-freepbx_service_|-freepbx_|-running:
            ----------
            __run_num__:
                34
            changes:
                ----------
            comment:
                Service freepbx is already enabled, and is running
            name:
                freepbx
            result:
                True

Before, it used to look similar to what the Master outputs (Colourless):

----------
    State: - service
    Name:      freepbx
    Function:  running
        Result:    True
        Comment:   Service freepbx is already enabled, and is running
        Changes:

I find that the output is not that clear, long and the colours are barely readable on a white terminal background.

So, Is there an option that allow's me to get the "old" output?
If not, could I ask why it was changed like this?

Lastly, if I must keep this output, Is there a way to make it more readable like the default output I get on the Master? (Green means good, Teal means it changed and Red means an ERROR)

Thanks,
Marc

[basepi]

First of all, what version are you running? salt-call --versions-report

It looks like salt-call is not properly receiving the out key in the return dictionary, and so is not using the correct outputter. We'll look into it.

[mlebel]

Sure, here it is...

Salt: 0.16.0-3514-g7063499
Python: 2.7.3 (default, Jan 13 2013, 11:20:46)
Jinja2: 2.6
M2Crypto: 0.21.1
msgpack-python: 0.1.10
msgpack-pure: Not Installed
pycrypto: 2.6
PyYAML: 3.10
PyZMQ: 2.2.0
ZMQ: 2.2.0

...I had tried to play with the outputer in the minion file but without any success.

Thanks for looking into it!

[regilero]

In fact my #7466 bug is maybe related. It seems the output function now receive a dictionnary with one extra deep level that make the whole output code fail silently with such results (and Traceback in case of config syntax error instead of showing it).

[basepi]

@mlebel can you try testing on the latest develop branch? Just want to make sure it's still a bug.

@regilero Yes, it may well be related.

[mlebel]

@basepi Tried the develop branch...

root@master1:~/# salt --version
salt 0.17.0

And it is still broken in this version...

@regilero I like how you took that to another level...good work...

[basepi]

OK, thanks. We'll figure out why it's choosing the wrong outputter.

In the meantime, you can use --out highstate to force it to use the correct outputter.

[mlebel]

Thanks but unfortunately salt-call --out highstate state.highstate doesn't work either.

It spits out the same output...

[basepi]

Really? o.O

OK, thanks, we'll get this tracked down.

For kicks and giggles can you try salt-call state.highstate --out=highstate? I doubt it will work, but my brain wants you to try it anyway.

[mlebel]

LOL... the command ran fine but with the same output...

Thanks for tracking it down, i'll be around for more testing should you need it :-)

[basepi]

Hehe, so no change? Figured as much.

[mlebel]

OK.. so I tested some more this weekend.. Hopefully this might help you track this down easyier...

I found that when choosing different outputers, naturally, I get different results.. But the results for all that I tried still appears to be in "debug" mode..

For example, with YAML as the outputer:

service_|-freepbx_service_|-freepbx_|-running:
      __run_num__: 38
      changes: {}
      comment: Service freepbx is already enabled, and is running
      name: freepbx
      result: true

And with JSON as the outputer:

"service_|-freepbx_service_|-freepbx_|-running": {
                "comment": "Service freepbx is already enabled, and is running",
                "__run_num__": 38,
                "changes": {},
                "name": "freepbx",
                "result": true
            },

Anyway, hope that helps...

[terminalmage]

It looks like I may have introduced this regression when I added my state summary. Looking into this now.

[terminalmage]

OK, this is not being caused by my state summary, but an exception was being caught while tallying up those results, which was caused by something else entirely. I've fixed the problem and will have details in a pull request shortly.

[terminalmage]

Details (and fix) in #7522.

[mlebel]

Hmm, I hope replying to this will re-open the issue.. it's still not fixed...

Edit: I guess it doesn't... Can we re-open this ticket?

I installed the devel branch first.
0.17.0
When running salt or salt-call I get the following traceback. (unknown if it's related to "today's fix")

[WARNING ] Although 'lspci' was found in path, the current user cannot execute it. Grains output might not be accurate.
[INFO    ] Executing command 'ps -efH' in directory '/root'
[ERROR   ] An un-handled exception was caught by salt's global exception handler:
TypeError: __init__() takes at most 3 arguments (4 given)
Traceback (most recent call last):
  File "/usr/bin/salt-call", line 11, in <module>
    salt_call()
  File "/usr/lib/pymodules/python2.7/salt/scripts.py", line 77, in salt_call
    client.run()
  File "/usr/lib/pymodules/python2.7/salt/cli/__init__.py", line 303, in run
    caller.run()
  File "/usr/lib/pymodules/python2.7/salt/cli/caller.py", line 135, in run
    ret = self.call()
  File "/usr/lib/pymodules/python2.7/salt/cli/caller.py", line 78, in call
    ret['return'] = func(*args, **kwargs)
  File "/usr/lib/pymodules/python2.7/salt/modules/state.py", line 253, in highstate
    st_ = salt.state.HighState(opts, pillar, kwargs.get('__pub_jid'))
  File "/usr/lib/pymodules/python2.7/salt/state.py", line 2353, in __init__
    self.state = State(self.opts, pillar, jid)
TypeError: __init__() takes at most 3 arguments (4 given)
Traceback (most recent call last):
  File "/usr/bin/salt-call", line 11, in <module>
    salt_call()
  File "/usr/lib/pymodules/python2.7/salt/scripts.py", line 77, in salt_call
    client.run()
  File "/usr/lib/pymodules/python2.7/salt/cli/__init__.py", line 303, in run
    caller.run()
  File "/usr/lib/pymodules/python2.7/salt/cli/caller.py", line 135, in run
    ret = self.call()
  File "/usr/lib/pymodules/python2.7/salt/cli/caller.py", line 78, in call
    ret['return'] = func(*args, **kwargs)
  File "/usr/lib/pymodules/python2.7/salt/modules/state.py", line 253, in highstate
    st_ = salt.state.HighState(opts, pillar, kwargs.get('__pub_jid'))
  File "/usr/lib/pymodules/python2.7/salt/state.py", line 2353, in __init__
    self.state = State(self.opts, pillar, jid)
TypeError: __init__() takes at most 3 arguments (4 given)

Then I ran my script which compiled version 0.17.0-250-g5140c33 and I got the same "debug" ouput that I originally posted about...

service_|-freepbx_service_|-freepbx_|-running:
            ----------
            __run_num__:
                38
            changes:
                ----------
            comment:
                Service freepbx is already enabled, and is running
            name:
                freepbx
            result:
                True

@terminalmage I got your message while editing this one... sorry, I wasn't sure if it would post, so that was just a test... (now I know) :-)

[terminalmage]

@mlebel Please provide more details, then. I tested and the issue is fixed for me.

[basepi]

Just FYI, edits to posts never send new e-mails, even if you mention someone. I pinged @terminalmage, so he should look at this shortly. =)

[mlebel]

ahhh...that is good to know..LOL Thanks @basepi

[terminalmage]

@mlebel 0.17.0-250-g5140c33 is still 165 commits behind where #7522 was merged. Can you please update your checkout and try again?

[mlebel]

@terminalmage If the fix is applied in dev, which it appears it is. Then in my test above, I had the correct version in the first case i listed. But this first case fails with a traceback error while running both salt or salt-call...

I tested all kinds of different versions i could find today and I couldn't get passed that traceback.
I will open another ticket for that traceback and report back here later if needed.

Thanks!

[terminalmage]

@mlebel Sorry, I don't understand what you're getting at. The first time you posted the output to salt-call --versions-report you came up with 0.16.0-3514-g7063499. The next time, you mentioned that you had updated to 0.17.0-250-g5140c33, which is 250 commits after the 0.17.0 release. The fix was merged at 0.17.0-415-gd9f5afb which is 165 commits newer than 0.17.0-250-g5140c33 (415 - 250 = 165).

So, you could not possibly have had the "correct version" unless you were using something 0.17.0-415-gd9f5afb or newer.

I don't know what you mean by "I tested all kinds of different versions i could find today". If you just install from git, you'll have a new enough version, which is why I asked you do do that in my previous comment.

[mlebel]

@terminalmage I believe I didn't explain myself properly. To clarify, I am referring to my post where I asked for the ticket to be re-opened. In that post, I gave two different versions of salt that I tested.

In the first version, which was downloaded directly from the develop branch on the website. I copied the zip file over to my server and proceeded to extract it and compile everything into installable packages. This version turned out to be the 0.17.0 version. (as reported by salt-call --version) This version is the one that I ran into the traceback error that i posted in the above post in question..

In my past experience with using salt, whenever commits were done, I had always seen the changes by using my script to re-compile salt. So I thought I will try my script.

So this is where I ended up compiling salt 0.17.0-250-g5140c33 (the actual command used in my script is "git clone https://github.com/saltstack/salt.git"). And this version ran fine except that the "debug" output was still there. As you explained why I still saw it, I was left wondering why I didn't have the latest version with my script. So I browsed through commits and tried downloading some version that started with a long string of numbers.. Anyway, that didn't work either.

I hope this helps...and perhaps I can be steered in a better direction if it exists :-)

[mlebel]

@basepi and @terminalmage I opened another ticket for the traceback and it was closed referencing '#7565'. Now that this is fixed I looked at cloning the develop branch and for the right syntax for it.
looks like i found it.

git clone -b develop https://github.com/saltstack/salt.git

That finally got me 'salt-call 0.17.0-465-g44d40db'..

Now, on to the real test for the salt-call output.... Drumm roll..... Fail...
I swear I still get the "debug output" as described in my original post.

[terminalmage]

You do know that you can just use git pull to update a cloned repo, right? You don't have to keep cloning the repo.

At any rate, I'm still not able to replicate this, even with an up-to-date git checkout. Whatever you're experiencing is likely an artifact of the odd way you're installing salt.

[mlebel]

@terminalmage Thanks for the tip on git pull, I will adjust my script accordingly... It definitely will make things faster in the future...

Either way, here is a list of the commands used to compile the salt debs:

git clone -b develop https://github.com/saltstack/salt.git
cd salt/
fakeroot debian/rules binary

Then I copy and install the debs to each machine. (I found this way of doing it in the salt docs a while back) (I also did it this way to get the debs working on rasberry pi's) To me, this seems pretty standard...

Now to prove or disprove our points, I used the same compiled debs (0.17.0-465-g44d40db) on another machine, a regular pc this time with debian wheezy installed on it.
Sure enough, as you stated, it worked.

Now, I'm pretty sure that there's something about this rasbian/raspbx system running on the raspberry pi that is causing this error. Since this error is new and everything worked before, then I feel that something was perhaps missed somewhere.

How do you suggest we approach this problem?

[terminalmage]

As far as I am concerned, this issue is fixed. There is nothing architecture-specific in the code that would have caused that error.

[mlebel]

Alright thanks, it must be another bug unrelated to this one..

[basepi]

@mlebel Can you try installing via the instructions here? http://docs.saltstack.com/topics/installation/index.html#platform-specific-installation-instructions

Then, when 0.17.0 is installed, get the latest develop (either via pull or clone), then, when in that checkout, run the following command:

sudo python setup.py install --force

Then restart the master and minion. I don't know what you're doing with the debs, but I want to make sure you have a good install. A clean machine would be even better, then follow the above steps. I've never heard of anyone installing salt the way you're describing, and I want to make sure that it's not an artifact of your install method, like @terminalmage mentioned.

[basepi]

Actually, just noticed you were talking about raspbian. In that case, you probably can't use the Debian instructions (not sure either way), but the setup.py method should still work, assuming you have the dependencies installed.

[mlebel]

This discussion is continued in #7591...