Change:
import ( "flag" "fmt" <ins> "io/ioutil" </ins> "os" "time" <ins> "github.com/golang/glog" </ins> "github.com/onsi/ginkgo/config" "github.com/spf13/viper" <ins> restclient "k8s.io/client-go/rest" </ins> "k8s.io/client-go/tools/clientcmd" <ins> clientcmdapi "k8s.io/client-go/tools/clientcmd/api" </ins> "k8s.io/kubernetes/pkg/cloudprovider" "k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig" "k8s.io/kubernetes/pkg/kubemark"

Discussion:
/kind feature I am running self-hosted E2E conformance tests in a pod on every freshly deployed cluster (similar as in ). is started without any host, kubeconfig configuration and picks up the InClusterConfig correctly. All conformance tests pass nicely, except from kubectl executions. kubectl gets executed by as and therefore fails on connection refused. In the container running kubectl without --server, will work as expected, since I have service accounts set up correctly. Looking into code, for some reason defaultHost is set to http://127.0.0.1:8080 ( ). That value is not used within as it seems, but is passed on to kubectl, only. Omitting would let the kubectl run with no problem, why is it set to that value (default proxy port is 8001)? Currently I am mitigating by pre-exectuting before running
/sig Testing
This is known, and there is a means to circumvent by passing in a kubeconfig. I've had a todo to fix this for a while, but I'll prioritize to get this fixed sooner. fyi -
can you please leave some notes on how you wanted to fix this? i can take a shot at it
if you can write the in-cluster config out and set KUBECONFIG prior to the kubectl tests that would help.
: ack. : Can you please send me the list of tests that fails? So i can be sure my changes will work for you?
- reviewing the code paths PR should do the trick, but would like to get that list of failed tests so i can confirm. Thanks, Dims
every conformance test that's shelling out kubectl is failing (20-some of the 150 conformance tests). as elegant as your PR looks, I think it won't work, due to authentication: kubectl will work out of the box on a pod with InClusterConfig, however, as soon as you start specifying one single parameter (such as --server), even if you do not change it compared to InClusterConfig, you will need to specify the rest, too. There might be two ways to do it: write out a kubeconfig file and reference it omit when shelling out to kubectl IMHO, the second option is much more elegant, but would need to test to confirm it works.

e2e AND kubectl work with InClusterConfig by themselves, why not leave it that way and only change anything, iff e2e gets any parameters (-host) specified. Otherwise, InClusterConfig should work as designed.
can you give me the list of the 20 tests please?
Sure, rerunning the tests, might take an hour.
Here's the first one: The rest will follow as a list.
It is a 1.7.2 test running against a 1.7.7 cluster.
See, there are three variants on how to invoke kubectl: Only the third one gets to the API and and gets authorized. If I had a kubeconfig file, that would also work.
Excellent! thanks will take a look at the scenarios. thanks for digging in.
/assign
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details