Silent failures in stand-alone Salt minion

2
votes

I'm starting a project which uses Salt Stack to coordinate provisioning. But it isn't working now -- the log file (on the minion, at /var/log/salt/minion) isn't showing any errors, but the minion isn't doing what I ask it to.

Basically, I'm building up a SaltStack with a couple of top files and at least two minion configs. In particular, I'm debugging a minion I'm calling bootstrap (because it's supposed to bootstrap a salt master on the minion):

master: localhost
file_client: local
file_roots:
  base:
    - /srv/salt/base
    - /srv/salt/states
  master:
    - /srv/salt/master
    - /srv/salt/master/states

As far as I can tell, Salt is loading up the top files just fine, and is parsing them into valid objects, but Salt is not running any commands in response to the objects. Indeed, the minion log file says:

2014-03-01 23:00:09,644 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/base', '/srv/salt/state
2014-03-01 23:00:09,651 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/base/top.sls:
base:
  '*':
    - edit.vim
    - essential
    - users.root

2014-03-01 23:00:09,656 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('base', OrderedDict([('*', ['edit.vim', 'essential', 'users.root'])]))])

That all looks okay, except that it immediately jumps to:

2014-03-01 23:00:09,661 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/master', '/srv/salt/mas
2014-03-01 23:00:09,662 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/master/top.sls:
master:
  '10.47.94.0/24':
     - match: ipcidr
     - master
     - srv.dns.unbound

2014-03-01 23:00:09,665 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('master', OrderedDict([('10.47.94.0/24', [OrderedDict([('match', 'ipcidr')]), 'master', 'srv.dns.unbound'])]))])

In the entire rest of the log file, base is never mentioned again. And the commands/states associated with base are not getting run. I do see log entries for edit.vim, srv.dns.unbound, etc. But they all follow the same pattern: parse and do nothing.

What am I doing wrong? I get the vague impression that it has to do with having multiple file_roots in my minion config, but I'd rather not make architectural changes until I know what the architecture should be. (I had already tried to use Salt once before, ran into "this" silent error, started over, and now ran into it again)

2
salt-stack
Can you try running salt * test.ping to confirm that the salt master is able to communicate with the minion (and also check whether the salt minion has had its key accepted by the master)? - Jason Zhu
@JasonZhu: I don't have a master yet. This stack is supposed to define a master-less minion which runs a master. So the idea is, I'd provision this machine and have the rest of my salt stacks use it as the master. - nomen
Have you solved it? You could try to run salt-call --local test.ping to see if it rings a bell. - leonardinius

2 Answers

1
votes
master: localhost
file_client: local

The 'master: localhost' and 'file_client: local' options are mutually exclusive.

If you have 'file_client: local' then the local salt-minion will not look for a master at all.

If want to run a salt-master and a salt-minion on the same machine, then you would use 'master: localhost' in the minion config and leave 'file_client' commented out. In that case, you'd also keep your minion and master configs separate.

As far as your question about the top.sls files rendering. That's according to design. Salt will look for and render each top.sls in the root of each file environment. So because you have two environments it's always going to render both top.sls files and then evaluate them for each minion to determine with sls files to execute on each minion.

It will take some more information to troubleshoot why the states in your base environment aren't being executed. Try running the following command and providing the output:

salt-call state.show_highstate -l debug
1
votes

This is usual confusion as I start reading saltstack document.

  1. Always stick to master-minion setup, avoid any attempt to play or even "think as masterless". Going Masterless doesn't save you much of CPU&mem resources, but create more confusion for saltstack learning/building process.

  2. Always draw a logical diagram than "think straight into saltstack".

  3. Always write down the proper/explicit file path and name when asking question ,i.e. for config files,states, etc. , don't take shortcut.

I would like to do the similar, i.e. Use my intranet salt-master name AA provision a salt master X in datacenter D , then start minion provision from salt master X.to control all the minion inside data center D.

So it is logical to do this

Salt master AA <-> (Datacenter D 

Server XYZ [Salt master X, Salt minion X to AA ],
 Server S_1 [Salt minion S_1, salt-master X ], 
 Server S_2 [Salt minion S_2, salt-master X ],
 Server S_3 [Salt minion S_3, salt-master X ]

)

So salt master AA will control Server XYZ as a minion. Then I can send the next level of control code from master AA to Server XYZ, perhaps run a automation script to uninstall the salt minion connector in AA.