Better stdout support

[jtopjian]

Unless I've missed something in the docs, the stdout of runners is restricted to a sub-portion of the overall runner output.

While most tools that we would house under st2 are cron, batch, daemon, and other types of non-interactive actions, there are some reporting tools where the full, unaltered output is necessary.

The best I've been able to come up with is reviewing the results of the last runner through the audit history.

I noticed that the Roadmap includes better output support -- is this the same thing?

[Kami]

I believe all the runners (local, remote and python) should return a full output unless the script / action being executed does some weird buffering. There are some cases where we manipulate the output and this might be where the problem lies.

If you can share the action (and the expected output) where you encountered this problem I can have a look and try to reproduce it.

On a related note, I believe there is a known limitation with a remote runner with an action which uses sudo (stdout and stderr are combined):

 # XXX: For sudo, fabric requires to set pty=True. This basically combines stdout and
# stderr into a single stdout stream. So if the command fails, we explictly set stderr
# to stdout and stdout to ''.
 if result['failed'] and result.get('stdout', None):
    result['stderr'] = result['stdout']
    result['stdout'] = ''

[jtopjian]

@Kami Sorry, I should have been more clear. It's not so much that the output is cut off, it's that it's squeezed inside a fixed-sized box:

| result          | {                                                            |
|                 |     "failed": false,                                         |
|                 |     "stderr": "",                                            |
|                 |     "return_code": 0,                                        |
|                 |     "succeeded": true,                                       |
|                 |     "stdout": "+--------------------------------------+----- |
|                 | ----+--------+------------+-------------+------------------- |
|                 | ----+                                                        |
|                 | | ID                                   | Name    | Status |  |
|                 | Task State | Power State | Networks              |           |
|                 | +--------------------------------------+---------+--------+- |
|                 | -----------+-------------+-----------------------+           |
|                 | | 739647b3-d824-4e43-a3ff-65c6323367cc | jttest  | ACTIVE |  |
|                 | -          | Running     | default=192.168.1.100 |           |
|                 | | 855afb2d-2a1a-4a30-b91d-d8eb76355682 | jttest2 | ACTIVE |  |
|                 | -          | Running     | default=192.168.1.102 |           |
|                 | +--------------------------------------+---------+--------+- |
|                 | -----------+-------------+-----------------------+           |
|                 | "                                                            |
|                 | }                                                            |

[Kami]

@jtopjian Ah, thanks. That's actually just the user-friendly formatting which is enabled in the CLI by default.

You can retrieve the raw response as returned by the API by passing -j flag (j as in json) to the command.

For example:

st2 run -j core.local cmd=date

I recently just added some documentation for the CLI, but it doesn't include the section about retrieving raw output - I will update it today and make sure it also includes section about the output formatting :)

[jtopjian]

@Kami Yup, I saw the -j flag in the -h output. Here's what I get:

       "stdout": "+--------------------------------------+---------+--------+------------+-------------+-----------------------+\n| ID                                   | Name    | Status | Task State | Power State | Networks              |\n+--------------------------------------+---------+--------+------------+-------------+-----------------------+\n| 739647b3-d824-4e43-a3ff-65c6323367cc | jttest  | ACTIVE | -          | Running     | default=192.168.1.100 |\n| 855afb2d-2a1a-4a30-b91d-d8eb76355682 | jttest2 | ACTIVE | -          | Running     | default=192.168.1.102 |\n+--------------------------------------+---------+--------+------------+-------------+-----------------------+\n",

[Kami]

@jtopjian This is looks fine though, right? Or am I missing something?

Printing result.stdout should return the same output as it output by the action (\n line break characters will be replaced with the actual new line).

[jtopjian]

@Kami Here's the output I'd like to see, without anything else printed from st2:

+--------------------------------------+---------+--------+------------+-------------+-----------------------+
| ID                                   | Name    | Status | Task State | Power State | Networks              |
+--------------------------------------+---------+--------+------------+-------------+-----------------------+
| 739647b3-d824-4e43-a3ff-65c6323367cc | jttest  | ACTIVE | -          | Running     | default=192.168.1.100 |
| 855afb2d-2a1a-4a30-b91d-d8eb76355682 | jttest2 | ACTIVE | -          | Running     | default=192.168.1.102 |
+--------------------------------------+---------+--------+------------+-------------+-----------------------+

It's not that these commands return their own table-formated data -- this can apply to a myriad of other cases (a list of users, for example) where I just want the raw, unobstructed output of the runner.

Does that make sense?

[jfryman]

I see @jtopjian's case as being a common use case as users bring in existing scripts, with their own existing formatting and whatnot. In order to smooth the transition, we need to have a command that a user can run a remote- or local- runner and have the behavior be the exact same until such time as they're able to go into these scripts and adapt them to being parsed by StackStorm.

So, the command date +%sand st2 run core.local cmd='date +%s' should essentially output the same thing (ex: 1423494017)

I don't know where in the model this fits (parameter of metadata, a flag at runtime, ENV vars... whatever), but I see the use being important in the first scenario where users will only want to audit and collect history of commands already being run to gain confidence in the system.

[jtopjian]

@jfryman That's an interesting view. It sounds to me like I'm shoe-horning some existing scripts into st2? If that's the case, what would be the proper long-term way of modifying our existing reporting tools into st2? Or are these types of tools not suited for st2?

IMO, by not having an easy way to bundle these types of tools into st2 (not just for an initial conversion, but for long-term use), then st2 is checking off every box except one: the need for sysadmins/operators to run frequent/common queries against their environment. These tools would then need housed under a separate repo or other aggregation command.

[jfryman]

@jtopjian I'm not sure that you're shoe-horning, so to say. One of our major goals is to allow users to import their existing scripts and be useful. So, if you import a script with all intentions to use it with StackStorm, and it doesn't behave in the same manner as it did before (except with all the StackStorm trimmings - audit, history, RBAC (:soon:)), then it could hurt adoption.

Our goal however as users become more familiar with the system is to rip out any view logic, or logging logic, or any of the other things that come for free with StackStorm from scripts, and rely on our 'common currency', which is JSON to pass data around, and workflows to ultimately decide how and where output should be sent. Scripts should eventually be broken down into the smallest unit possible to decrease maintenance costs, and then any output (including shell commands) can be output as JSON, parsed by our libraries, and easily passed around as actual objects instead of the long commands that usually require a large dose of xargs and awk/sed. We'll be providing libraries for internal formatting and table output like you have currently in your scripts.

So, again... not so much shoe-horning as it is a transition path. As your scripts become simpler, you'll see this need become less and less. But, we still need a path for you (and others) to get from A->Z.

@jtopjian Certainly open to input you have on how you'd use this for your own use case.

[jtopjian]

@jfryman OK, I think I'm starting to understand. So, let's say st2 was totally complete, then any type of action that I implement in st2 should ideally return a json result?

Then depending on where the action was called (command-line, web ui, etc), the result would be formatted appropriately?

[Kami]

@jtopjian

@Kami Here's the output I'd like to see, without anything else printed from st2:

You can do that by passing -k flag to the execution get command (this flag specifies which key to print). For example:

st2 execution get 54d8c52e0640fd1c87b9443f -k stdout

Output:

Mon Feb  9 14:33:18 UTC 2015

[jtopjian]

@Kami ah, nice! Now if this was available under st2 run, it would save us from having to run two commands where originally outside of st2 it would be one command 😄

[Kami]

@jtopjian Agreed - that's something @jfryman and I have just talked about on slack. run should take the same flags as execution get.

@manasdk IIRC, you added support for -k and other flags to execution get, right? If so, could you please do the same with run command?

I'm also just working on the documentation for output formatting and execution get flags right now, but this will need to be updated when we also add those flags to run command.

[jfryman]

LOL. TIL -k. I'll add this to our docs so it's a little better exposed

@jtopjian just to close the loop though. JSON is automatically parsed at each layer into an object for easier manipulation. Output formatting like prettytable once in JSON is not for free (yet), but we'll have libraries for these coming soon.

[Kami]

It looks like we got this resolved so I will close the ticket.

@jtopjian We will keep you posted on the progress of adding -k and other flags to the run command. And if you feel the problem hasn't been fully resolved yet, feel free to re-open this ticket or open a new one.

[jtopjian]

Just touching base on this. It looks like @m4dcoder added the -k support in 9b4b3be.

[livelace]

Hello. How I can improve formatting of chatops messages (slack/mattermost), if I get:

action: linux.traceroute
status : succeeded
web_url: https://stackstorm.xxx.com/#/history/58917da59ee97b0001268a0c/general
took: 12s
result :
46.101.xxx.xxx :
stdout : traceroute to ya.ru (93.158.134.3), 30 hops max, 60 byte packets 1 46.101.0.253 (46.101.0.253) 0.337 ms 46.101.0.254 (46.101.0.254) 0.326 ms 0.307 ms 2 138.197.249.226 (138.197.249.226) 0.322 ms 0.315 ms 138.197.249.242 (138.197.249.242) 0.273 ms 3 138.197.249.217 (138.197.249.217) 0.280 ms 138.197.249.215 (138.197.249.215) 0.265 ms linx-gw.yandex.net (195.66.226.69) 6.306 ms 4 jansson-et-4-1-0.yndx.net (213.180.213.95) 34.308 ms linx-gw.yandex.net (195.66.226.69) 6.454 ms jansson-et-4-1-0.yndx.net (213.180.213.95) 34.266 ms 5 jansson-et-4-1-0.yndx.net (213.180.213.95) 34.260 ms 34.233 ms std-p2-hu0-1-0-1.yndx.net (213.180.213.125) 56.139 ms 6 std-p2-hu0-1-0-1.yndx.net (213.180.213.125) 57.387 ms ugr-b-c1-ae1.yndx.net (87.250.239.47) 55.121 ms std-p2-hu0-1-0-1.yndx.net (213.180.213.125) 55.721 ms 7 ugr-b-c1-ae1.yndx.net (87.250.239.47) 55.475 ms 55.478 ms 55.483 ms 8 58917da59ee97b0001268a0b systemd-private-060050b9b8fa4efdbef98597989d38a7-openvpn@server.service-Hswvnk tmux-0 www.yandex.ru (93.158.134.3) 56.766 ms 55.358 ms 9 58917da59ee97b0001268a0b systemd-private-060050b9b8fa4efdbef98597989d38a7-openvpn@server.service-Hswvnk tmux-0 58917da59ee97b0001268a0b systemd-private-060050b9b8fa4efdbef98597989d38a7-openvpn@server.service-Hswvnk tmux-0 www.yandex.ru (93.158.134.3) 56.705 ms 10 58917da59ee97b0001268a0b systemd-private-060050b9b8fa4efdbef98597989d38a7-openvpn@server.service-Hswvnk tmux-0 www.yandex.ru (93.158.134.3) 55.829 ms 55.811 ms

It seems that stdout cannot be formatted well. It's unreadable.

[arm4b]

@livelace As described in Slack, behind the scenes st2 action:

st2 run linux.traceroute host=google.com

Executes the following script:

/opt/stackstorm/packs/linux/actions/traceroute.sh google.com

The problem was in original traceroute.sh which eats new lines, not StackStorm.

By design StackStorm shows what he get from the script via stdout, stderr and exit code.

Anyways, here is a small fix for linux.traceroute action: #3175