Tag: onchanges

REQUISITES AND OTHER GLOBAL STATE ARGUMENTS

The Salt requisite system is used to create relationships between states. The core idea being that, when one state is dependent somehow on another, that inter-dependency can be easily defined. These dependencies are expressed by declaring the relationships using state names and ID’s or names. The generalized form of a requisite target is <state name> : <ID or name>.

Requisites come in two types: Direct requisites (such as require), and requisite_ins (such as require_in). The relationships are directional: a direct requisite requires something from another state. However, a requisite_in inserts a requisite into the targeted state pointing to the targeting state. The following example demonstrates a direct requisite:

vim:
  pkg.installed

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc
    - require:
      - pkg: vim

In the example above, the file /etc/vimrc depends on the vim package.

Requisite_in statements are the opposite. Instead of saying “I depend on something”, requisite_ins say “Someone depends on me”:

vim:
  pkg.installed:
    - require_in:
      - file: /etc/vimrc

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc

So here, with a requisite_in, the same thing is accomplished as in the first example, but the other way around. The vim package is saying “/etc/vimrc depends on me”. This will result in a require being inserted into the /etc/vimrc state which targets the vim state.

In the end, a single dependency map is created and everything is executed in a finite and predictable order.

REQUISITE OVERVIEW

name
of

requisite

 state is only executed if target execution

result is

 state is only executed if target has

changes

 order

1.target 2.state (default)
comment
or

description
require success default state will always execute unless target fails
watch success default like require, but adds additional behaviour (mod_watch)
prereq success has changes (run individually as dry-run) switched like onchanges, except order
onchanges success has changes default execute state if target execution result is success and target has changes
onfail failed default Only requisite where state exec. if target fails

In this table, the following short form of terms is used:

  • state (= dependent state): state containing requisite
  • target (= state target) : state referenced by requisite