testing sate.highstate when minions run on a schedule

[Seth Madison]

I'm a very new salt person, coming from a puppet world, and one thing I have not yet been able to figure out is how to properly test new code.

In the simplest case, I have a salt minion and a salt master running on the same machine, and the salt minion runs with a schedule (either from its pillar data or in its config). I would like to be able to easily disable the scheduled runs if the master's file_root is not on the production branch so that I can run noops (test=True) on my production servers against non-production code. Ideally there'd be a way to do this without having to actually change the code. Here are some of the two ideas I had for the single master/minion case:

 - Keep the schedule in the config file, and make a separate config dir for testing. In this case testing, would require stopping the minion and pointing it to a different config dir.

 - Put the schedule into pillar data, and have some sort of check in the pillar for which branch the master is on. I ruled this one out since you can't call a module from a pillar sls, and grains are cached.

[Dan Garthwaite]

Salt recommends setting up different state trees for your environments:
http://docs.saltstack.com/topics/tutorials/states_pt4.html

Now you can either declare what minions are in what environment by listing them in /srv/salt/top.sls or set grains on the minion and use grain targeting in the same top.sls file.

  -dan

[Seth Madison]

The issue with using environments in my current setup is that my schedules are defined in the config file, not in pillars, so I could end up automatically running my dev environment against a production node by accident.

Again, the use-case is testing new code on production systems. I want to be able to run state.highstate test=True against a new branch on a production node without risking that my schedules kick in and actually run the new branch with side effects.

I think one solution is to dynamically define the environment based off of a grain (maybe a file or some-such), and then put the schedule back into a pillar. Something like this:

pillar/top.sls:

------------------

'base':

  '*':

    schedule:

      highstate:

        function: state.highstate

        minutes: 60

'test':

  '*':

    schedule: {}

master config:

---------------------

file_roots:

  base:

     - /srv/salt/

  test:

     - /srv/salt/checkout_on_another_branch

top.sls

----------

base:

  '*':

    - somestate

test:

  'env:test':

    - match: grain

Would that work? Wouldn't somestate.sls still come off of the base tree? Also, I would need to restart the minion for this to take affect, because the grain would be cached, and so salt wouldn't notice when I change the file. Can anybody think of a more elegant solution?