salt --async emitting jid and general methods of capturing it between platforms

[arizvisa]

Description of Issue

This is not an issue, but probably a question that leads towards a feature request. When using the salt client with the --async (or the --show-jid) option, extra text is emitted in order to describe to the caller what is being returned. As an example, using the --async parameter the following message is emitted.

$ salt --async $id test.ping
Executed command with job ID: 20191006185730665675

If one wants to capture the job id from their shell, this extra text will need to be culled out through some means. For some shells, such as on a bourne-like shell they'll need to combine it with other commands like in the following:

$ jid=`salt --async $id test.ping | cut -d: -f2 | tr -d' '`

If using the windows command prompt, one'll probably use something similar to the following to extract the job id.

> for /f "tokens=2 delims=:" %T in ('salt --async %id% test.ping') do @set jid=%T

Then Powershell which might be considered simpler by some...

PS> (salt --async $id test.ping).Split(":")[-1].Trim() | Set-Variable jid

However, If one uses the --show-jid option, the --out=quiet parameter can be passed as in the following which makes capturing a little simpler perhaps.

$ salt --out=quiet --show-jid $id test.ping
jid: 20191006193152611760

One minor issue of --show-jid is that the job id is being emitted in a hardcoded format (can't convert to json/yaml/etc. w/ an outputter). Ftr the format of this is at salt/client/__init__.py:990. The primary issue with this, however, is that it appears that this format is unable to be combined with --async in order to run a job in the background which makes it not possible for saving the jid for a long-running job.

So...Is there some way to make the salt client emit just the job id and nothing else? If not, would you guys accept a PR for something like a -j option that emits just the job-id? This way scripters can simply just assign the job id for a job to a variable (generally) across platforms.

Rather than emitting the job-id by considering another parameter, perhaps the regular output of --async could be split across stdout+stderr so its simpler to capture the job id by discarding stderr.

Or perhaps another (more consistent?) way would be to feed the output of the job id from --async through the outputter that was specified. This way one can include a minimalistic outputter that emits just the jid, and specify --async --out=my-jid-emitter if they desire that particular capability.

Ftr, the line of code that (explicitly) emits the async job id is at salt/cli/salt.py:153.

salt/salt/cli/salt.py

Lines 153 to 157 in be9879c

	if self.config["async"]:
	jid = self.local_client.cmd_async(**kwargs)
	salt.utils.stringutils.print_cli(
	"Executed command with job ID: {}".format(jid)
	)

Setup

Not really relevant.

Steps to Reproduce Issue

Please see description.

Versions Report

Since 2015.5

[dwoz]

Seems like it would make sense to have --async output the JID in via the configured outputter.

[arizvisa]

Totally agreed. Yet --show-jid doesn't follow that consistency as well and since it writes to stdout, it interferes with redirection.

At the risk of interfering with the output schema, does it make sense to emit an array of associative-arrays where the first element would be the jid, and the second would be the result? Or should the jid be merged into the list of minions (which has the side effect of "jid" being a minion id).

Or should it be writing to stderr or allow the user to specify an alternative fd to write it to so that way it doesn't interfere with the result output?

[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.