Is your feature request related to a problem? Please describe.
When SaltGUI outputs state information, it presents all available data.
The original salt commands uses variables such as state_output and state_verbose to reduce the state related output.

Describe the solution you'd like
SaltGUI should use similar formatting on states.
By default, the original variables should be

The latest sizing recommendation is that bluestore DB partitions should not be smaller then 4% of the size of the data partition. We should consider this in our default deployments, maybe even check if this recommendation is not met.

The idea is to provide a low level interface to call salt modules without the need to have a Call object. This should make it easy to call functions that are not implemented as Call objects yet.

As it stands right now, salt-lint doesn't really use any big parts of the salt library. However, salt is marked as a dependency, meaning it must be pulled in and installed in its entirety. When creating a docker image to use, adding the salt libraries (including pycrypto and gcc for pycrypto), the size goes from 186MB to 416MB.

I made a PR (#120) to remove salt as a dependency, but it sounds li

First of all congrats on a new UI for salt, this looks promising.

It would be nice to have a --verbose option to know what it is doing (at least when starting to use pepperboard).

Salt TestSuite Documentation: https://docs.saltstack.com/en/latest/topics/development/tests/index.html#salt-s-test-suite

Checkout: saltstack/salt#53566

Speed improvements

• identify slow tests (use profiler)
• Investigate the reason of the slowest tests: saltstack/community#95
• create PR to improve performance

Par

Files output by the tool do not maintain YAML comments.

One consequence is that trying to mask jinja code using comments will result in the jinja being stripped from the resulting file. As the tool will not parse files with naked jinja using comments would be the only good way to preserve it.

something like this should be allowed:

foo:
# {%- if grains['envtype'] == 'dev' %}
    bar

I think that we don't need the github.io page really and the documentation would be simpler if we use only markdown ( is more accessible).

Once we have the markdown we could think to have diff section like
Readme.md
00_getting_started.md
01_advanced_stuff.md
02_examples.md

So the readme can more easy to navigate