This avoids some conflict with the built-in `flag` module in Go. The
module was already being renamed to `verflag` on import anyways, so we
might as well just call it that.
Tested:
- hack/build-go.sh and ran the resulting binaries with -version args.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This can be helpful to print the internal fields of the version
information that will contain more details about the git tree than the
short -version output will.
Tested:
- Tested getting the raw version:
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"0", Minor:"1+", GitVersion:"v2.2.1-33-gdc4becd9765393", GitCommit:"dc4becd9765393fa05a3eb06f6af9e00068fe0c5", GitTreeState:"dirty"}
- Tested getting the simple version:
$ _output/go/bin/kubecfg -version
Kubernetes version 0.1+, build dc4becd976
- Tested getting the help output:
$ _output/go/bin/kubecfg 2>&1 | grep -- -version
-version=false: Print version information and quit
- Made sure -version=true and -version=false works, that -version with
an invalid argument works as expected (prints usage help) and that
-version followed by space will not try to use the next word as its
argument (i.e. `-version raw` prints the version but not the raw one.)
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
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>
This is a very simple Makefile that just passes through to the current hack/*
scripts. Only "make", "make test", and "make clean" are supported for now.
This is some cleanup that has been needed for a while.
There's still one more step that could usefully be done, which is to
split up our api package into the part that provides the helper
functions and the part that provides the internal types. That can come
later.
The v1beta1 package is now a good example of what an api plugin should
do to version its types.
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>
