Skip to content

[FEATURE REQUEST] Provide master option to prefix state IDs with their sls variable #66168

@nf-brentsaner

Description

@nf-brentsaner

Is your feature request related to a problem? Please describe.
I received an internal request at our org to prefix state IDs (which currently are short descriptive phrases of the function being performed) with the dot-formatted SLS path ({{ sls }}) or the path syntax ({{ slspath }}) so the SLS file they exist in can be more easily identifiable by other maintainers.

Rather than going through and adding something like "{{ sls }} Do Something for Foo:", I think it would be great if the master had an output option to automatically prepend or append this string to state IDs when rendering output/results of jobs.

It seems that it already does this internally in some contexts anyways?

Describe the solution you'd like
A state would be defined as, e.g.:

Do Something Here:
  test.nop:
    - name: 'This is an example state.'

in <root>/some/sls/path/init.sls

But there would be an optional (disabled by default) option in the master config to report output as:

<MINION_ID>:
----------
# (...)
          ID: some.sls.path Do Something Here
    Function: test.nop
        Name: This is an example state.
      Result: True
     Comment: Success!
     Started: 20:18:48.804844
    Duration: 0.537 ms
     Changes:

Or, alternatively,

<MINION_ID>:
----------
# (...)
          ID: Do Something Here
         SLS: some.sls.path
    Function: test.nop
        Name: This is an example state.
      Result: True
     Comment: Success!
     Started: 20:18:48.804844
    Duration: 0.537 ms
     Changes:

Describe alternatives you've considered
Going through every single one of our states and adding it.

Hoping and praying that others remember to do it as well for new states.

Additional context
N/A

Please Note
If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Featurenew functionality including changes to functionality and code refactors, etc.needs-triage

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions