* Rewrite a bunch of the hack/ directory with modular reusable bash libraries.
* Have 'build/*' build on 'hack/*'. The stuff in build now just runs hack/* in a docker container.
* Use a docker data container to enable faster incremental builds.
* Standardize output to _output/{local,dockerized}/bin/OS/ARCH/*. This regularized placement makes cross compilation work.
* Move travis specific scripts under hack/travis
With new dockerized incremental builds, I can do a no-op `make quick-release` in ~30s. This is a significant improvement.
This lets us blow away salt files and replace them with a new version while keeping a tree of "overlay" files that are cluster specific and generated at cluster up time.
Fixes#1783
The `systemctl enable` command ordinarily prints the `ln` command used
to enable the unit to stderr, but that's not ideal in the vagrant setup
because it gets printed in red, which should be reserved for errors, but
it's not a real error.
Set an environment variable to raise the log level to prevent `info`
messages from being printed to stderr (as they are not actually errors.)
I looked into the `systemctl` calls happening from the Salt setup script
to understand why they were not going to stderr, and it turns out the
Salt script will redirect all messages to stdout so they will all be
green regardless...
Tested:
- Started a fresh Vagrant cluster, confirmed no red messages in output
when creating the cluster successfully. Successfully started nginx
through Kubernetes using cluster/kubecfg.sh.
- Confirmed that the salt-api service was up after `vagrant up`:
$ vagrant ssh master -c 'systemctl status salt-api.service'
salt-api.service - The Salt API
Loaded: loaded (/usr/lib/systemd/system/salt-api.service; enabled)
Active: active (running) since Fri 2014-08-29 23:19:47 UTC; 11min ago
Main PID: 2090 (salt-api)
CGroup: /system.slice/salt-api.service
+-2090 /usr/bin/python /usr/bin/salt-api
+-2110 /usr/bin/python /usr/bin/salt-api
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
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>
The most recent saltstack bootstrap file expects a salt-api service to
exist. The most recent Fedora salt-master rpm doesn't include this
service yet. Pointing to the previous version of the bootstrap script.
Haney Maxwell