The workaround was not needed, as salt-minion was always correctly
started in the Vagrant minion setup.
The issue reported in #270 was clearly specific do System V style init
scripts and will not affect systemd.
Also remove the inaccurate comment from provision-master.sh, since -X
was not even really in use there.
Tested:
- Performed 3 full `vagrant up` and `vagrant destroy -f` cycles with at
least 3 minions and up to 6 minions in one case. Checked that
salt-minion was up in each of the minions using a `systemctl status
salt-minion` command.
- Started nginx on the cluster using cluster/kubecfg.sh, confirmed it
was up with `list /pods` and confirmed it was reachable using wget on
port 8080 of the minions.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
The `which` command in Fedora 20 (differently from the one in Debian)
prints to stderr when the binary is not found. Redirect both stdout and
stderr to /dev/null to prevent messages from being printed by `which`.
Check whether the binary exists or not by the exit status of `which`
(non-zero means the binary does not exist) instead of checking for empty
output.
Tested:
- Started a Vagrant cluster with `vagrant up` and confirmed these
messages were gone. Checked master and minions for Kubernetes
components using the systemd status commands.
- Confirmed that the same error message for salt-minion is also
suppressed from the output with this patch.
Fixes: Issue #1079
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Joe Beda