In a large SLS tree, it often becomes reasonable to have SLS files include other SLS files. This is done using an include block, which usually appears at the top of an SLS file:

include:
  - base
  - emacs

In this example, the SLS file in question will replace the include block with the contents of base.sls (or base/init.sls) and emacs.sls (or emacs/init.sls). This imposes some important restrictions on the user. Most importantly, the SLS files that are included may not contain IDs that already exist in the SLS file that includes them.

It is also important to remember that include itself, being a top-level declaration, cannot exist twice in the same file. The following is invalid:

include:
  - base
include:
  - emacs

State SLS files are unique among configuration management formats in that they are both declarative and imperative. They are imperative, as each State will be evaluated in the order in which it appears in the SLS file. They are also declarative because States may include requisites that change the order in which they are actually executed. For instance:

web_service:
  service.running:
    - name: apache2
    - require:
      - pkg: web_package
web_package:
  pkg.installed:
    - name: apache2

If a service is declared, which requires a package that appears after it in the SLS file, the pkg States will be executed first. However, if no requirements are declared, Salt will attempt to start the service before installing the package, because its codeblock appears before the pkg codeblock. The following will require two executions to complete properly:

web_service:
  service.running:
    - name: apache2
web_package:
  pkg.installed:
    - name: apache2

Requisites point to a list of items elsewhere in the SLS file that affect the behavior of the State. Each item in the list contains two components: the name of the module and the ID of the State being referenced.

The following requisites are available inside Salt States and other areas of Salt that use the State compiler.

apache2:
  pkg:
    - installed
    - require
      - file: apache2
  service:
    - running
    - require:
      - pkg: apache2
  file:
    - managed
    - name: /etc/apache2/apache2.conf
    - source: salt://apache2/apache2.conf

apache2:
  ...SNIP...
  service:
    - running
    - require:
      - pkg: apache2
    - watch:
      - file: apache2
  ...SNIP...

apache2:
  service:
    - running
    - onfail
      - pagerduty: apache_failure

apache2_conf:
  file:
    - managed
    - name: /etc/apache2/apache2.conf
    - user: root
    - group: root
    - mode: 755
    - watch_in:
      - service: apache2
mysql_conf:
file:
  - managed
    - name: /etc/mysql/my.cnf
    - use:
      - file: apache2_conf
    - watch_in:
      - service: mysql

There are some situations in which a State does not need to run, unless another State is expected to make changes. For example, consider a Web application that makes use of Apache. When the codebase on a production server changes, Apache should be turned off, so as to avoid errors with the code that has not yet finished being installed.

The prereq requisite was designed exactly for this kind of use. When a State makes use of prereq, Salt will first perform a test run of the State to see if the items referred to in the prereq are expected to make changes. If so, then Salt will flag the State with the prereq as needing to execute.

apache2:
  service:
    - running
    - watch:
      - file: codebase
codebase:
  file:
    - recurse
...SNIP...
shutdown_apache:
  service:
    - dead
    - name: apache2
    - prereq:
      - file: codebase

In the preceding example, the shutdown_apache State will only make changes if the codebase State reports that changes need to be made. If they do, then Apache will shutdown, and then the codebase State will execute. Once it is finished, it will trigger the apache2 service State, which will start up Apache again.

Each of the aforementioned requisites can be used inversely, by adding _in at the end. For instance, rather than State X requiring State Y, an SLS can be written so that State X declares that it is required by State Y, as follows:

apache2:
  pkg:
    - installed
    - require_in:
      - service: apache2
  service:
    - running

It may seem silly to add inverses of each of the States but there is in fact a very good use case for doing so: include blocks.

SLS files cannot use requisites that point to a code that does not exist inside them. However, using an include block will cause the contents of other SLS files to appear inside the SLS file. Therefore, generic (but valid) configuration can be defined in one SLS file, included in another, and modified to be more specific with a use_in requisite.

In addition to an include block, State SLS files can also contain an extend block that modifies SLS files that appear in the include block. Using an extend block is similar to a use requisite, but there are some important differences.

Whereas a use or use_in requisite will copy defaults to or from another State, the extend block will only modify the State that has been extended.

# cat /srv/generic_apache/init.sls)
apache2_conf:
  file:
  - managed
    - name: /etc/apache2/apache2.conf
    - source: salt://apache2/apache2.conf
(In django_server/init.sls)
include:
- generic_apache
extend:
  apache2_conf:
    - file:
    - source: salt://django/apache2.conf
(In image_server/init.sls)
include:
  - generic_apache
extend:
  apache2_conf:
    - file:
      - source: salt://django/apache2.conf

The preceding example makes use of a generic Apache configuration file, which will be overridden as appropriate for either a Django server or a Web server that is only serving images.