Is salt-run supported on masterless minions?

[sandy]

Is salt-run supported on masterless minions?

Is salt-run supported on masterless minions where any/all potential tgt: directives evaluate to minion on which salt-run is running?  Thus the salt-run functions ultimately only run on the minion.

The reason for asking is a new incoming request to port a bunch of salt and salt-run states to a single node (single minion) topology and I was wondering if for simplicity the single node systems can be set up masterless.  

Thanks much in advance, particularly for any details so to be able to evaluate the potential for success.

-sandy

 

[Seth House]

You can put the `salt-run` script on a masterless minion by installing
the `salt-master` package, even if you don't start or use the Master
daemon. That said, a lot of Runner functions are expecting to be run
from a Master which means they're expecting a running Master daemon
and an active ZMQ connection to send commands through.

To your question about writing for Orchestrate states vs regular
Minion-side states: Orchestrate is just a Master-side state run, it
has access to all the same state functions and uses 99% of the same
code-paths as a Minion-side state run. A good rule-of-thumb is to
write most all your states as though they will run locally, directly
on the system they are configuring. And then the role of Orchestrate
is to call those already-written states and perform any cross-minion
coordination. In a Masterless setup there is obviously no cross-minion
coordination and so you simply call the same states directly that
Orchestrate would have called.

Hopefully that's helpful, if a little high-level. If you have more
questions or if there are gray-areas, please post some code snippets
that we can explore.

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

[Daniel Wallace]

You could also use `salt-call saltutil.runner` to run the runner and not need the salt-run binary.

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.saltutil.html#salt.modules.saltutil.runner

> email to salt-users+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

[sandy]

Thanks - that actually helps a lot.

FWIIW I started out creating a lot of orchestration states (maybe 2 dozen?) that called minion side states, but it became too messy and the UX (end user experience/interface) was a significant challenge for users.  So I converted +90% of master side orchestration states to a single python script which improved things significantly for the end users (the users who operate the clouds that salt is managing).  They now just interface to a a stupid (sic) python wrapper that then calls into salt/salt-call/salt-run.  But there are still a few orchestration states left.

So cool - will try converting the remaining salt-run states to local-run states and will reply back when it is over and comment on the success of it.

Thanks!

[Loren Gordon]

If it helps, there is a bit of work in the develop branch that allows using state.orchestrate on a masterless minion.

https://github.com/saltstack/salt/pull/33837

-Loren

[sandy]

Interesting - did not realize this is possible.  Even though at this point the states have been converted to local states, will definitely keep this note around just in case.  Thanks!

[sandy]

FYI - I converted the orch states to local states and everything went well except for one thing - the return code/value of the converted states seems to be set to 11 (failure) as opposed to 0 (success) on those nodes where nothing happens.

Here is an example of an orchestration .sls before the conversion:

# How to start accumulo

# Just start it on the master
{% from 'include/accumulo-vars.sls' import ACCUMULO_MASTER with context %}

start accumulo ({{ ACCUMULO_MASTER }}):
  salt.function:
    - name: cmd.run
    - tgt: {{ ACCUMULO_MASTER }}
    - tgt_type: list
    - arg:
      - runuser -l oaduser -c "monit start accumulo-master"

And here is an example of the same file after:

# How to start accumulo

{% set NODE_ID = pillar['cluster-settings']['node-id'] %}
{% from 'include/accumulo-vars.sls' import ACCUMULO_MASTER with context %}

{% if ACCUMULO_MASTER == NODE_ID %}

start accumulo ({{ ACCUMULO_MASTER }}):
  cmd.run:
    - name: runuser -l oaduser -c "monit start accumulo-master"

{% endif %}

The problem with the above is that on salt 2016.3.3 CentOS 6.8, the local state variant returns a minion error on all the nodes that do not run the 'start ...' state (where the NODE_ID is not equal to ACCUMULO_MASTER), like the following:

$ sudo salt foo-stage06 state.sls orch/services/accumulo-start
foo-stage06:

Summary for foo-stage06
-----------
Succeeded: 0
Failed:   0
-----------
Total states run:    0
Total run time:  0.000 ms
ERROR: Minions returned with non-zero exit code        <<<<==== returns a retcode of 11 and not 0

If I add a dummy function to the bottom of the file like this:

# How to start accumulo

{% set NODE_ID = pillar['cluster-settings']['node-id'] %}
{% from 'include/accumulo-vars.sls' import ACCUMULO_MASTER with context %}

{% if ACCUMULO_MASTER == NODE_ID %}

start accumulo ({{ ACCUMULO_MASTER }}):
  cmd.run:
    - name: runuser -l oaduser -c "monit start accumulo-master"

{% endif %}

Clear out mystery error for accumulo-start.sls {{ NODE_ID }}:
  test.nop: []

The the mystery salt error is cleared out and the calling function (the script/wrapper/stuff that is calling the salt command to orchestrate (in this case start only) the accumulo service no longer trips over the error.

Any comments on this?  Is the above code wrong or is there a bug somewhere or ...

Thanks much again.
-sandy