Current BuildConfigFromFlags() seems to print a log like below when
config path isn't specified:
```
W0120 15:30:06.196820 13323 client_config.go:359] error creating
inClusterConfig, falling back to default config: %vunable to load
in-cluster configuration, KUBERNETES_SERVICE_HOST and
KUBERNETES_SERVICE_PORT must be defined
```
This commit removes the needless "%v"
If not, using `go test -count=n` would make them pile up and ultimately
get to the limit of open files:
client_test.go:522: expected an error, got Get http://127.0.0.1:46070/api: dial tcp 127.0.0.1:46070: socket: too many open files
Steps to reproduce (no longer fails):
godep go test -short -run '^$' -o test .
./test -test.run '^TestGetSwaggerSchema' -test.count 100
Note that this might not fail if your `ulimit -n` is not low enough.
I broke out the error retry logic into a named function that could be
tested independently of the rest of the event processing framework. This
allows the test to know when the retry logic is done.
The problem with the original test was there was no reliable way to know
when it was done trying record an event. A sentinal event was being
used, but there is no ordering guarantee. I could have added
synchronization around attempts tracking to fix the data race, but the
test case was still fundamentally flawed and would error occasionally.
If not, using `go test -count=n` would make them pile up and ultimately
get to the limit of open files:
2015/12/05 12:43:56 http: Accept error: accept tcp 127.0.0.1:39768: accept4: too many open files; retrying in 5ms
2015/12/05 12:43:56 http: Accept error: accept tcp 127.0.0.1:46606: accept4: too many open files; retrying in 5ms
2015/12/05 12:43:56 http: Accept error: accept tcp 127.0.0.1:46606: accept4: too many open files; retrying in 10ms
2015/12/05 12:43:56 http: Accept error: accept tcp 127.0.0.1:46606: accept4: too many open files; retrying in 20ms
Steps to reproduce (no longer fails):
godep go test -short -run '^$' -o test .
./test -test.run '^TestDoRequestNewWayFile$' -test.count 100
Note that this might not fail if your `ulimit -n` is not low enough.
