Include multiple salt states in specific order - salt-stack

Question

I want to compose multiple existing salt states into a new one, where they need to be executed in a specific order.
The SaltStack documentation explains that salt states can be included.
As I understand, the included states will be run before the rest of the sls file.
Example:
include:
- config-pulled
- service-restarted
Using this example, I want service-restarted to be executed after config-pulled and only if config-pulled was successful.
But the execution order of multiple included states is not guaranteed. The docs say:
... If you need to guarantee order of execution, consider using requisites.
I could imagine to use requisities directly on the include. For example:
include:
- config-pulled
- service-restarted:
require:
- config-pulled
But this does not work.
Questions
How to use requisites when including states?
Do I have to use an orchestrate script instead?

Answer 1

You don't have to use orch and you can use onchanges requisites with a test.succeed_with_changes.
tested on salt 3004.2
To sum up the demo, onchanges inhibits the execution of the test.succeed_with_changes by default unless there is a change in the given state (tests.config-pulled). onchanges_in does the same the other way around and inhibits server reload unless test.succeed_with_changes is modified (in the salt sense).
Example:
/srv/salt
├── tests
│   ├── config-pulled.sls
│   ├── init.sls
│   └── service-restarted.sls
config-pulled.sls
config-pulled:
file.managed:
- name: /tmp/config
- contents: 1000
# uncomment random to simulate a change (or change 1000 just over)
# - contents: {{ range(1000, 9999) | random }}
service-restarted.sls
service-restarted:
cmd.run:
- name: echo service-restarted
init.sls
include:
- tests.config-pulled
- tests.service-restarted
demo:
test.succeed_with_changes:
- onchanges:
- sls: tests.config-pulled
- onchanges_in:
- sls: tests.service-restarted
This approach might become a bit difficult to maintain.
A completely different approach would be a reorganization of sls.
I usually separate server install and reload from customization (two separate sls), therefore when I have to handle configs, I include the "install and reload" one (usually init.sls) on top of any/all the sls managing the conf to import the states and configure my config states with require_in, ex:
myconf:
file.managed:
- [...]
- require_in:
- cmd: rndc-reload
or
myconf:
file.managed:
- [...]
- require_in:
- service: haproxy
Note: this approach scale well as several states or even sls can manage configs using this mechanism and the daemon will be reloaded only once after all configs are set.
UPDATE
Add output to show specific order
Without changes
# salt-call state.apply tests
local:
----------
ID: config-pulled
Function: file.managed
Name: /tmp/config
Result: True
Comment: File /tmp/config is in the correct state
Started: 14:49:20.363480
Duration: 15.688 ms
Changes:
----------
ID: demo
Function: test.succeed_with_changes
Result: True
Comment: State was not run because none of the onchanges reqs changed
Started: 14:49:20.380447
Duration: 0.004 ms
Changes:
----------
ID: service-restarted
Function: cmd.run
Name: echo service-restarted
Result: True
Comment: State was not run because none of the onchanges reqs changed
Started: 14:49:20.380536
Duration: 0.002 ms
Changes:
Summary for local
------------
Succeeded: 3
Failed: 0
------------
Total states run: 3
Total run time: 15.694 ms
With changes
# salt-call state.apply tests
local:
----------
ID: config-pulled
Function: file.managed
Name: /tmp/config
Result: True
Comment: File /tmp/config updated
Started: 14:49:15.757487
Duration: 18.292 ms
Changes:
----------
diff:
---
+++
## -1 +1 ##
-1001
+1002
----------
ID: demo
Function: test.succeed_with_changes
Result: True
Comment: Success!
Started: 14:49:15.777084
Duration: 0.549 ms
Changes:
----------
testing:
----------
new:
Something pretended to change
old:
Unchanged
----------
ID: service-restarted
Function: cmd.run
Name: echo service-restarted
Result: True
Comment: Command "echo service-restarted" run
Started: 14:49:15.777785
Duration: 7.69 ms
Changes:
----------
pid:
4130033
retcode:
0
stderr:
stdout:
service-restarted
Summary for local
------------
Succeeded: 3 (changed=3)
Failed: 0
------------
Total states run: 3
Total run time: 26.531 ms

Answer 2

includes are not states. so requisites will not work with them.
as for the ticket you pointed to that became https://docs.saltproject.io/en/latest/ref/states/all/salt.states.test.html#salt.states.test.nop test.nop which is just a state that doesn't do anything.
for handling what you are talking about you would do something like
include:
- http
- libvirt
run_http:
test.nop:
- require:
- sls: http
run_libvirt:
test.nop:
- require:
- test: run_http
- sls: libvirt