SaltStack states and requisites
Salt states are the declarative side of Salt. They describe how a machine should look, while requisites describe how the pieces should be applied in relation to one another.
Core model
The docs describe SLS files as structured state data, usually written in YAML and commonly rendered through jinja|yaml. In practice that means a state file is not just shell automation in disguise. It is a data structure that Salt compiles into a predictable execution plan.
Typical state files manage packages, files, users, groups, services, and command execution while expressing how those pieces depend on each other.
Why this part of Salt is powerful
- State files are declarative enough to stay readable.
- The model scales from a single
init.slsto larger trees coordinated throughtop.sls. - Jinja gives just enough dynamism to handle platform differences and repeated patterns.
- The result is close to how Linux administrators already think: package first, config next, service after, restart only when needed.
Requisites that matter most
requireenforces dependency ordering.watchreacts to changes and usually triggers service restarts or similarmod_watchbehavior.onchangesis useful when an action should happen only after a real change.listenkeeps state order intact and defers reactive behavior to the end of the run.includeandextendlet state trees grow without copying everything into one file.
Practical design lesson
Good Salt state trees feel like careful systems thinking, not clever templating. The best ones are explicit about IDs, requisites, and boundaries between reusable building blocks.