search

saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
https://repo.saltproject.io/
Apache License 2.0
14.15k stars 5.47k forks source link

Add a new flag as an alternative to --out #15131

Closed whiteinge closed 7 years ago

whiteinge commented 10 years ago

The current --out flag is minion-centric which means it can't be used to display summary or aggregate data. We've worked around this recently by adding additional output options to the CLI. Unfortunately this output is only available via the CLI and not at the Python-level and it is not available as structured output (e.g. JSON).

I'd like to propose a new flag that uses existing outputter modules (as well as new, yet-to-be-written outputter modules) that are run once at the end.

Benefits & features:

  1. Can collect summary information and aggregate stats. (Total highstate failures, total minions returned/not-returned.)
  2. Available programmatically in structured output formats. The Python API and salt-api will be able to call these modules with return data and produce the same summary/aggregate data as the CLI.
  3. Namespace the return data for future additions. Something like how salt-api has a return key for the minion returns. This will allow us to add summary or failure or similar extra data. No need to retain backward compat since we're not modifying --out.
  4. Allow arguments. It would be very useful to devise a scheme for passing arguments to these modules to modify the output on the fly. These arguments should be available at the CLI as well as in the lowdata for salt-api. Perhaps --format-json-arg1-arg2 or --format-json --format-json-arg1 --format-json-arg2?
whiteinge commented 10 years ago

See also: #11199, #8341, #8180, #7664, #6580.

cachedout commented 10 years ago

I dealt with this exact limitation yesterday when trying to structure output of minions that didn't return for different reasons. An output aggregator is sorely needed.

pwaller commented 10 years ago

I don't really understand how anyone is using salt in large deployments at the moment. We don't have a large deployment, it's only 8 boxes. But we have maybe up to a 500-1000 states and salt is very hard to use in a reliable manner. If there are failures one has to scroll through a large amount of output, and it is unclear how to invoke code based in changes or failures, for example to create a central log which just listed "things which failed or changed". I've raised this in a mailing list post before but ultimately didn't find much useful to go on.

basepi commented 10 years ago

@pwaller Wow! That's a lot of states!

This is a problem we're aware of and working on. I want to sit down with some of our community members sometime who manage large infrastructures, and pick their brains about their workflows with salt. My guess is that many of them are using some custom tooling to parse the large output of salt. Hopefully we can get some salt-conf talks on this subject. We also want to improve the outputter such that instead of just outputting on a per-minion basis we can output based on the complete results of the run, and get statistics that way. Maybe print a summary of all failures across all minions at the bottom of the state run, for example. Plus success/changed/failed statistics from the whole run, in addition to a per-minion basis.

stale[bot] commented 7 years ago

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.