Debugging States from a non-master Location

[Kevin]

I understand the use of the '-l debug' command-line option and the test=True module option for debugging states on the salt master (or via salt-call on the minion), but I'm not clear on how I could debug states that have not been placed on the master yet. Consider this scenario:

I'm on my development host writing a salt state and I want to test out the state I just wrote before committing it to the repository (e.g. does this jinja template output what I think it will on host32a?). Let's say in this case that even my lowest environment ('dev') would be unhappy if this jinja template change went badly. If I commit the template without testing it, it immediately ends up at the master, and if master is doing automatic highstate runs (let's say it's every 15 mins), I have a limited window in which to log on to the master and test out the render of this jinja template before it auto-runs a highstate and does something potentially nasty to all of my minions.

So, is there any way to run a very basic test of rendering jinja templates or states without being on the master? Could I maybe take the master's key and key cache to my development host so it could act as a sort of "sandbox master" where I only run things in test=True? Anyone have suggestions on the best way to go about this?

Thanks!

-Kevin

[C. R. Oldham]

You don't really need a sandbox master, you can do this almost entirely on a machine with salt installed--it doesn't even need to be running a minion.  Put an appropriate approximation of your pillar data in a directory, and the state files in another directory on the machine where you will test.  Then run

salt-call --local --pillar-root=<pillar location> --file-root=<state file location> state.sls <sls file to test> test=True

and/or experiment with state.show_highstate, show_low_sls, or show_lowstate (https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.show_highstate)

Does that help?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--cro

C. R. Oldham, Platform Engineer, SaltStack

c...@saltstack.com / 801-564-4673

[Kevin Newman]

Yeah, that should do nicely! I was totally unaware I could call it locally like that. Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/FXpCdnye28c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Kevin]

Sorry, one more thing. I'm not sure this entirely solves my issue.

Is there any way for this salt-call --local to masquerade as a different host? I'm particularly interested in being able to debug what a template would output given a certain host's set of grains. This method of using salt-call --local seems like it would only be effective if running it on the host that I wanted to test as.

Example: My dev box is host32a. I want to test out how this template would look as compiled on host46b. Is there any way to do that without copying my dev branch's file_root and pillar data to host46b and using salt-call?