New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sequential operation relatively impossible currently #13657

Closed
ryan-lane opened this Issue Jun 23, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@ryan-lane
Contributor

ryan-lane commented Jun 23, 2014

Due to the requisites system modifying the order of states, it's currently impossible to ensure sequential ordering of states unless you can live without watch/watch_in.

It would be nice if there was a requisite that could be used to trigger states that would always occur at the end of the run and wouldn't re-order the states at all.

@UtahDave

This comment has been minimized.

Member

UtahDave commented Jun 24, 2014

We had a good discussion about this. We've come up with the following example. We're thinking of calling it the listen state with a changes function.

So let's consider this simple set of states. We install apache and manage a couple config files.
We want to restart apache if our config files change, but we want the restart to happen as the very last action. The mod_watch() function gets called just like in a "watch"

apache2:
  pkg.installed

/etc/myapp/myapp.conf:
  file:
    - managed
    - source: salt://myapp/myapp.conf

/etc/app2/app2.conf:
  file:
    - managed
    - source: salt://app2/app2.conf

restart_our_apache:
  listen:
    - changes
    - name: pkg.apache2
    - listen:
      - file: /etc/myapp/myapp.conf
      - file: /etc/app2/app2.conf

The listen state can be placed anywhere as many times as needed. So if you want to have something restart half way through, you can put it there, or at the end or wherever.

Also we can restart (or rather, call the mod_watch() function) for multiple states like this:

apache2:
  pkg.installed

run_this_thing:
  cmd.script:
    - source: salt://run_this_script.sh

/etc/myapp/myapp.conf:
  file:
    - managed
    - source: salt://myapp/myapp.conf

/etc/app2/app2.conf:
  file:
    - managed
    - source: salt://app2/app2.conf

restart_stuff:
  listen:
    - changes
    - listen:
      - file: /etc/myapp/myapp.conf
      - file: /etc/app2/app2.conf
    - action:
      - service: apache2
      - cmd: run_this_thing

What are your thoughts on this? Does listen.changes work for you?

@ryan-lane

This comment has been minimized.

Contributor

ryan-lane commented Jun 24, 2014

As mentioned in IRC, this needs to work in a way where the state can say "these files notify this state" as well as "this state is notified by these files". Kind of like a requisite, but one that doesn't modify ordering.

Otherwise, you may have a large number of sls files that could change and the state referencing files in them would be invalid.

By being able to specify "this file notifies this state" you could even wrap the state in an if that ensures the state exists (formulas, for instance).

@basepi basepi added the Feature label Jun 24, 2014

@basepi basepi added this to the Approved milestone Jun 24, 2014

@UtahDave

This comment has been minimized.

Member

UtahDave commented Jun 25, 2014

@ryan-lane does that commit @thatch45 made last night satisfy your workflow here?

@ryan-lane

This comment has been minimized.

Contributor

ryan-lane commented Jun 25, 2014

I believe it will, yes.

@basepi

This comment has been minimized.

Member

basepi commented Jun 26, 2014

Awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment