Running orchestration with test=True

[clint...@ni.com]

I am writing some custom execution modules as part of a system build orchestration, and would like to be able to "dry-run" it.  I am porting most of the code over from Ansible, which has a "check mode" in which your code can check for a flag and not do any changes.
I know Salt has a "test=True" option, and I have checks for __opts__['test'] in my code to handle it.
However when I use the test flag, it doesn't try to run any code, it just says this:

----------
          ID: allocate_storage
    Function: salt.function
        Name: ldevblock.allocate
      Result: None
     Comment: Function ldevblock.allocate will be executed on target * as test=False
     Started: 11:06:23.366615
    Duration: 1.686 ms
     Changes:

Summary for mephisto.natinst.com_master
------------
Succeeded: 1 (unchanged=1)
Failed:    0
------------
Total states run:     1
Total run time:   1.686 ms
retcode:
    0

Is there a way to have orchestrate runner run my code so I can do a "dry-run"?

[Seth House]

Salt's dry-run mode is specific to _state modules_ and does not do
anything special for _execution modules_. It works like this:

1. Several of the functions in the `state.py` execution module accept
a `test=true` keyword argument.

2. Those functions kick off a state run by instantiating a class that
handles Salt's state system. If that keyword argument is `true` then
the value you referenced in `__opts__` is set to `true` for the
duration of that state run and any state functions can check that
value.

Since your custom `ldevblock.allocate` function is an execution function

> --
> 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.

[Seth House]

Whoops. Hit send too early. Continued...

On Tue, Nov 15, 2016 at 11:52 AM, Seth House <se...@eseth.com> wrote:
> Since your custom `ldevblock.allocate` function is an execution function

Since your custom `ldevblock.allocate` function is an execution

function you should look for the `test` keyword argument that function
is called with instead of looking in __opts__. Or if it makes sense
for your workflow, you might want to create both an execution function
and a state function. The relationship between the two is roughly:

The execution function(s) do all the actual work. The state
function(s) call the execution modules in order to answer the
following questions:

* A pre-check -- does anything need to change?
* A dry-run check -- should I stop early because we're in dry-run mode?
* Alter the local system if things do need to change.
* A post-check -- what did change?

You can see a full example here:

https://docs.saltstack.com/en/latest/ref/states/writing.html#full-state-module-example

[Clint Allen]

Thanks for the explanation, it makes a lot more sense now. I'm still getting used to the multiple module types Salt has.

--
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/ObS3YhRlVks/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.