Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to get salt-minion to call salt-call with alternate configuration #46886
Description of Issue/Question
How do i get salt-minion to call salt-call with the correct configuration directory?
Issue is seen on versions from 2016.11.7 to 2018.3.0.
I'm hoping it's just a little config item i've missed...
systemd unit file for kmdpaas service (salt-minion)
Steps to Reproduce Issue
On the salt minion server:
At this point, you should see a set of processes like the following:
On the salt master server:
Now, some extra processes are seen on the minion:
That is, an extra salt-minion process has been started. This process has called salt-salt, but called with a wrong config_dir, even though the minion is started with the correct config_dir.
After a little bit of time, the salt-master tries to get status of the job (process list on minion):
And soon after the master sends out:
If I create an /etc/salt/minion that points to the correct master, or if i make "salt" resolvable, then there is no problems. Unfortunately, we need multiple salt-minions and salt-masters, so the custom config_dir is necessary in our setup.
Simplified reproduction method, leaving out the systemd entirely:
Change to the saltadm user
As an added bonus, managing variables becomes a bit easier/transparent, so I've also tested with the various variables that migt be of interest:
Result remains the same: default /etc/salt is passed to the salt-call command instead of the expected custom config directory.
In the file "salt/executors/sudo.py":
Change "salt.syspaths.CONFIG_DIR" to "opts.get('config_dir')"
I thought it already was... Of course, we've added the fix locally to all new installs until it comes in. It isn't in develop, so I've created a branch for this in the fork I've created and will try to do a pull request against that into develop. Not that I've had much luck getting things through so far...