Using requisite injection to order states

Given three states, /root/a, /root/b and /root/c, I want /root/c to execute before /root/b, and /root/b to execute before /root/a.

Given a Salt SLS file salt://ordertest/init.sls:

/root/a:
  file.managed:
    - source: salt://ordertest/a
    - user: root
    - group: root
    - mode: 600 

/root/b:
  file.managed:
    - source: salt://ordertest/b
    - user: root
    - group: root
    - mode: 600 

/root/c:
  file.managed:
    - source: salt://ordertest/c
    - user: root
    - group: root
    - mode: 600

I can test to see the order in which the listed states would be applied. You'll see /root/a precede /root/b, and /root/b preceed /root/c.

$ salt my-minion-id state.apply ordertest test=True
my-minion-id:
----------
          ID: /root/a
    Function: file.managed
      Result: None
     Comment: The file /root/a is set to be changed
     Started: 13:54:23.538144
    Duration: 31.765 ms
     Changes:
----------
          ID: /root/b
    Function: file.managed
      Result: None
     Comment: The file /root/b is set to be changed
     Started: 13:54:23.570065
    Duration: 16.632 ms
     Changes:
----------
          ID: /root/c
    Function: file.managed
      Result: None
     Comment: The file /root/c is set to be changed
     Started: 13:54:23.586831
    Duration: 17.124 ms
     Changes:

Summary for my-minion-id
------------
Succeeded: 3 (unchanged=3)
Failed:    0
------------
Total states run:     3
Total run time:  65.521 ms

If we use require to directly tell /root/b to require /root/, and /root/c to require /root/b:

```
/root/a:
file.managed:
- source: salt://ordertest/a
- user: root
- group: root
- mode: 600
- require:
- /root/b

/root/b:
file.managed:
- source: salt://ordertest/b
- user: root
- group: root
- mode: 600
- require:
- /root/c

/root/c:
file.managed:
- source: salt://ordertest/c
- user: root
- group: root
- mode: 600

This turns out to be a known issue:


The require_in requisite does not support everything that require does, mainly id does not support sls or state_id without specifying a state module.

So by modifying our SLS file to include the state module (specifying file: /root/b as the require_in target instead of simply /root/b), we get the correct result.

I don't know if the other requisite injectors (watch_in, etc.) have the same limitations, so I will likely standardize my coding style on explicitly including module names in such identifiers.

StackExchange DevOps Q#969, answer score: 5