How to define the output of salt status

30 views Asked by At

When I execute the module, its output is as follows:

{'TEST': {'pid': 116441,
  'retcode': 0,
  'stdout': '              total        used        free      shared  buff/cache   available\nMem:            503         341          31           3         131         120\nSwap:            31           0          31',
  'stderr': ''}}

When I execute the module via state, its output is as follows:

{'TEST': {'cmd_|-test_|-free -g_|-run': {'name': 'free -g',
   'changes': {'pid': 107058,
    'retcode': 0,
    'stdout': '              total        used        free      shared  buff/cache   available\nMem:            503         341          30           3         131         120\nSwap:            31           0          31',
    'stderr': ''},
   'result': True,
   'comment': 'Command "free -g" run',
   '__sls__': 'ha_action',
   '__run_num__': 0,
   'start_time': '15:44:10.604521',
   'duration': 141.64,
   '__id__': 'test'}}}

The first output is what I want. It has minion_id, and you can also directly get the execution status and execution output. The second kind of output is a little more complicated. I just want to get the execution output and status. This kind of display increases the complexity of getting it. Does Saltstack have parameters or methods to define the output format of state?

1

There are 1 answers

0
OrangeDog On

Does Saltstack have parameters or methods to define the output format of state?

Yes, Salt provides multiple output modules, and you can define any yourself.

With the CLI tools, the outputter is selected via the --out parameter.

If you are using an API such as LocalClient, then the output is a native data structure. It is trivial for you to convert that to whatever output you want.

for minion, result in data:
  for path, ret in result:
    print(str({minion: ret["changes"]}))

As for running it as a state vs. a module, the command free -g is not stateful in any way. If you're just doing it to monitor something, then it only makes sense to call it as a module.

There is also a builtin module for that check: status.meminfo.