TestCharts is failing

[strangepleasures]

When I try to build microbean with skipClusterTests=false I get the following error:

java.util.concurrent.ExecutionException: io.grpc.StatusRuntimeException: UNKNOWN: Get http://localhost:8080/version: dial tcp [::1]:8080: connect: connection refused

	at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:476)
	at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:455)
	at org.microbean.helm.chart.TestCharts.testRoundTrip(TestCharts.java:112)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: io.grpc.StatusRuntimeException: UNKNOWN: Get http://localhost:8080/version: dial tcp [::1]:8080: connect: connection refused
	at io.grpc.Status.asRuntimeException(Status.java:526)
	at io.grpc.stub.ClientCalls$UnaryStreamToFuture.onClose(ClientCalls.java:467)
	at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
	at io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:684)
	at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
	at io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:391)
	at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:475)
	at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:63)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:557)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:478)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:590)
	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.base/java.lang.Thread.run(Thread.java:844)

Output of helm version:

Client: &version.Version{SemVer:"v2.9.0", GitCommit:"f6025bb9ee7daf9fee0026541c90a6f557a3e0bc", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.0", GitCommit:"f6025bb9ee7daf9fee0026541c90a6f557a3e0bc", GitTreeState:"clean"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.10-gke.0", GitCommit:"16ebd0de8e0ab2d1ef86d5b16ab1899b624a77cd", GitTreeState:"clean", BuildDate:"2018-03-20T20:21:01Z", GoVersion:"go1.8.3b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): GKE

[ljnelson]

Hello; thanks for using microBean Helm. It's been a while since I've actively looked in this area of the codebase. Could you tell me where localhost:8080 is coming from? To my eyes, the configuration should be sourced from the strategy employed by new DefaultKubernetesClient(), which normally checks your ~/.kube/config file (as well as several environment variables). localhost:8080 is not really a value I'd expect for where a Kubernetes API server would be found. The root issue here, of course, is that no connection could be made to this host and port.

(Finally, I see from the stack trace that you are running with Java 9+. If it works for you, that's great; a heads up that I don't make any claims (yet) for Java versions above 8.)

[strangepleasures]

I don't have anything like localhost or 8080 in my ~/.kube/config.
Seems to be the same problem as in https://github.com/kubernetes/helm/issues/3986

[strangepleasures]

Also, switching to Java 8 doesn't make any difference.

[ljnelson]

Please note this is caused (ultimately) by helm/helm#2464 and is a Tiller configuration issue. This comment may help you fix your Tiller deployment. May I ask if you installed Tiller via the helm command line, or via a Java method in microBean Helm?

[ljnelson]

Actually, I withdraw that last question, as your version output indicates that you have installed Tiller version 2.9.0 (and microBean Helm would install version 2.8.2), so I can say with some certainty that you've installed Tiller using helm init or something similar.

I believe therefore since you have installed Tiller yourself using helm init or something similar, that you will almost certainly have to keep track of helm/helm#2464 to ensure that it is properly configured until the Helm developers (Tiller developers) truly fix the underlying issue.