running salt from cmd.run supported? #4298

Closed
Mrten opened this Issue Mar 27, 2013 · 7 comments

Comments

Projects
None yet
3 participants
Contributor

Mrten commented Mar 27, 2013

No description provided.

Contributor

Mrten commented Mar 27, 2013

To work around #4254 I've tried this in pillar:

#!mako|yaml

<%!
  import re
%>
<%
  ping = {}
  ping['virt'] = salt['cmd.run']("salt -G 'virtual:kvm' --verbose --timeout 1 --out text --static test.echo 'Minion return'")
  ping['phys'] = salt['cmd.run']("salt -G 'virtual:physical' --verbose --timeout 1 --out text --static test.echo 'Minion return'")

  out = {}
  for k,v in ping.iteritems():
    out[k] = []
    for line in v.split('\n'):
      line = line.strip()
      if line == "": continue
      if line.find('Minion') == -1: continue

      host = line[:line.find(':')]
      out[k].append('  - ' + host)

    out[k] = '\n'.join(out[k]);

%>

minions-all:
${out['phys']}
${out['virt']}

minions-physical:
${out['phys']}

minions-virtual:
${out['virt']}

This tries to (ab)use the fact that salt should return 'Minion has not returned' when, well, the minion does not return and --verbose is on. This did work (or so it seemed) when I only has one call to salt in the .sls, but now that I've got two calls to make a distinction between physical and virtual machines this runs into all kinds of strange behaviour. For starters, it waits a whole lot longer than 1 second (I've seen it take 60+, with a SaltReqTimeoutError exception in the master log), it never returns 'Minion has not returned' anymore, the command returns before the second answer is in, etc, etc.

So, should this be supported behaviour?

Owner

thatch45 commented Mar 27, 2013

Yes, we don't want to be executing salt calls from pillar, pillar needs to stay crazy fast. The solution I think is to fix #4254 by adding the master cache data to pillar

Contributor

Mrten commented Mar 27, 2013

I suppose running salt (the outer call) touches cache- or similar files in a way that confuses the inner two salt-calls?

(BTW, I don't think adding things like this to a pillar file slows it down as the pillars are only used from cached locations, right? It's only slow when you call refresh_pillar or pillar.data, not when the states run)

Owner

thatch45 commented Mar 28, 2013

The states refresh the pillar :)
Honestly I am not sure why this is causing problems, I do though think that adding this cache data directly to what pillar can use will solve a lot of problems and alleviate much of the peer usage out there

Collaborator

basepi commented May 28, 2013

#4254 is now closed, is this one resolved as well?

Contributor

Mrten commented May 29, 2013

You can say WONTFIX and I would understand that. There's the mine feature now, and the match module, so the original reason to abuse salt this way has gone away.

It's not fixed though, the sls above does not generate a list with all minions in it.

Collaborator

basepi commented May 29, 2013

Alright, then I'm going to close this. Glad that mine and match help you get around this restriction. =)

basepi closed this May 29, 2013

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