CODEWITHSUNDEEP
salt-project
mihca
mihca

Reputation: 1257

Include multiple salt states in specific order

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

Upvotes: 1

Views: 2159

Answers (2)

Damien
Damien

Reputation: 776

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

Upvotes: 1

whytewolf
whytewolf

Reputation: 704

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

Upvotes: 0

Related Questions