The main state file that instructs minions what environment and modules to use during state execution.
Configurable via state_top.
Occurs only in the top level of the highstate structure.
include: - edit.vim - http.server
Defines an individual highstate component. Always references a value of a dictionary containing keys referencing state declarations and requisite declarations. Can be overridden by a name declaration or a names declaration.
Occurs on the top level or under the extend declaration.
Must be unique across entire state tree. If the same ID declaration is used twice, only the first one matched will be used. All subsequent ID declarations with the same name will be ignored.
Until 0.9.6, IDs could not contain a dot, otherwise highstate summary output was unpredictable. (It was fixed in versions 0.9.7 and above)
Occurs only in the top level and defines a dictionary.
Extend declarations are useful for adding-to or overriding parts of a state declaration that is defined in another SLS file. In the following contrived example, the shown mywebsite.sls file is include -ing and extend -ing the apache.sls module in order to add a watch declaration that will restart Apache whenever the Apache configuration file, mywebsite changes.
include: - apache extend: apache: service: - watch: - file: mywebsite mywebsite: file: - managed
Occurs under an ID declaration.
A list containing requisite references.
Used to build the action dependency tree. While Salt states are made to execute in a deterministic order, this order is managed by requiring and watching other Salt states.
The name of the function to call within the state. A state declaration can contain only a single function declaration.
For example, the following state declaration calls the installed function in the pkg state module:
The function can be declared inline with the state as a shortcut, but the actual data structure is better referenced in this form:
httpd: pkg: - installed
Where the function is a string in the body of the state declaration. Technically when the function is declared in dot notation the compiler converts it to be a string in the state declaration list. Note that the use of the first example more than once in an ID declaration is invalid yaml.
httpd: pkg.installed service.running
When passing a function without arguments and another state declaration within a single ID declaration, then the long or "standard" format needs to be used since otherwise it does not represent a valid data structure.
httpd: pkg: - installed service: - running
Occurs as the only index in the state declaration list.
A single key dictionary referencing a Python type which is to be passed to the named function declaration as a parameter. The type must be the data type expected by the function.
Occurs under a function declaration.
For example in the following state declaration user, group, and mode are passed as arguments to the managed function in the file state module:
/etc/http/conf/http.conf: file.managed: - user: root - group: root - mode: 644
The name is always a single key dictionary referencing a string.
Overriding name is useful for a variety of scenarios.
For example, avoiding clashing ID declarations. The following two state declarations cannot both have /etc/motd as the ID declaration:
motd_perms: file.managed: - name: /etc/motd - mode: 644 motd_quote: file.append: - name: /etc/motd - text: "Of all smells, bread; of all tastes, salt."
Another common reason to override name is if the ID declaration is long and needs to be referenced in multiple places. In the example below it is much easier to specify mywebsite than to specify /etc/apache2/sites-available/mywebsite.com multiple times:
mywebsite: file.managed: - name: /etc/apache2/sites-available/mywebsite.com - source: salt://mywebsite.com a2ensite mywebsite.com: cmd.wait: - unless: test -L /etc/apache2/sites-enabled/mywebsite.com - watch: - file: mywebsite apache2: service: - running - watch: - file: mywebsite
For example, given the following state declaration:
python-pkgs: pkg.installed: - names: - python-django - python-crypto - python-yaml
Once converted into the lowstate data structure the above state declaration will be expanded into the following three state declarations:
python-django: pkg.installed python-crypto: pkg.installed python-yaml: pkg.installed
Here is the layout in yaml using the names of the highdata structure components.
<Include Declaration>: - <Module Reference> - <Module Reference> <Extend Declaration>: <ID Declaration>: [<overrides>] # standard declaration <ID Declaration>: <State Declaration>: - <Function> - <Function Arg> - <Function Arg> - <Function Arg> - <Name>: <name> - <Requisite Declaration>: - <Requisite Reference> - <Requisite Reference> # inline function and names <ID Declaration>: <State Declaration>.<Function>: - <Function Arg> - <Function Arg> - <Function Arg> - <Names>: - <name> - <name> - <name> - <Requisite Declaration>: - <Requisite Reference> - <Requisite Reference> # multiple states for single id <ID Declaration>: <State Declaration>: - <Function> - <Function Arg> - <Name>: <name> - <Requisite Declaration>: - <Requisite Reference> <State Declaration>: - <Function> - <Function Arg> - <Names>: - <name> - <name> - <Requisite Declaration>: - <Requisite Reference>
Current Salt release: 0.17.2
Docs for previous releases on salt.rtfd.org.
Enter search terms or a module, class or function name.