Relaxed requirements for version in kubeConfig

[piosz]

@gmarek

[piosz]

@caesarxuchao could you please take a look into this?

[gmarek]

Thanks @piosz. For the context: Heapster in Kubemark started crashlooping after recent version bump with error:

I0620 13:55:09.060836       1 heapster.go:65] /heapster --source=kubernetes:https://146.148.102.90:443?inClusterConfig=0&useServiceAccount=0&auth=/kubeconfig/kubeconfig
I0620 13:55:09.060931       1 heapster.go:66] Heapster version 1.1.0
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x18 pc=0x5daaeb]

goroutine 1 [running]:
panic(0x1786d00, 0xc820012060)
        /usr/lib/google-golang/src/runtime/panic.go:483 +0x3ef
k8s.io/heapster/common/kubernetes.GetKubeClientConfig(0xc820275930, 0x0, 0x0, 0x0)
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/common/kubernetes/configs.go:123 +0x3db
k8s.io/heapster/metrics/sources/kubelet.GetKubeConfigs(0xc820275930, 0xc8201aa350, 0x417101, 0x0, 0x0)
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/metrics/sources/kubelet/configs.go:39 +0x42
k8s.io/heapster/metrics/sources/kubelet.NewKubeletProvider(0xc820275930, 0x0, 0x0, 0x0, 0x0)
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/metrics/sources/kubelet/kubelet.go:319 +0x62
k8s.io/heapster/metrics/sources.(*SourceFactory).Build(0xc820275a40, 0x7fffe9b38dee, 0xa, 0x7fffe9b38df9, 0x5, 0x0, 0x0, 0x0, 0x7fffe9b38e01, 0x12, ...)
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/metrics/sources/factory.go:32 +0xaf
k8s.io/heapster/metrics/sources.(*SourceFactory).BuildAll(0xc820275a40, 0xc8201b78c0, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0)
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/metrics/sources/factory.go:46 +0xda
main.main()
        /usr/local/google/home/pszczesniak/go/src/k8s.io/heapster/metrics/heapster.go:76 +0x4c3

It seems that it's caused by the changes in kubeclient.

[k8s-bot]

Jenkins GCE e2e

Build/test passed for commit dfd777d.

• Build Log

[caesarxuchao]

I'd say you should set kubeConfig.GroupVersion at line 111, that's the only path that could end up with a nil GroupVersion and cause the panic. I don't know why this problem is exposed now.

[piosz]

Thanks @caesarxuchao

To give you more context this started failing after bumping the Kubernetes version in #1158 from kubernetes/kubernetes@644d651 (~late Feb 2016) to kubernetes/kubernetes@4bb30e0 (~mid May 2016). After that NewNonInteractiveDeferredLoadingClientConfig function started returning empty version.

[caesarxuchao]

Sorry I don't have time to investigate why NewNonInteractiveDeferredLoadingClientConfig() returns empty version. On the other hand, the version in the kubeconfig isn't useful currently, it will be given a default value anyway, so I can LGTM the PR. It's just that you might get surprises when we have more groups that have multiple versions and the default version isn't the one you want (currently only batch have two versions).

[piosz]

No worries. This is not high priority. Thanks for looking into it.

[mwielgus]

LGTM