add kubeconfig file properly

[deads2k]

This restores #2861, but it has an additional commit to fix two problems with loading existing .kubernetes_auth files that caused the e2e failure forcing #3282.

1. The Insecure options specified in a .kuberentes_auth file was clobbered by the insecure option in .kubeconfig. A test was added to be sure that this doesn't happen again.
2. The default --auth-path flag value (~/.kubernetes_auth) was lost. Because kubectl.sh special cases a non-default --auth-path for vagrant, this went unnoticed. I've restored the default and manually tested to be sure that ~/.kuberentes_auth is now read by default if no other authentication information is provided.

@derekwaynecarr Can you please take a look?

[zmerlynn]

Rebase? (I was about to double check the GKE provider as well but couldn't just yet.)

[deads2k]

@zmerlynn rebasing now. Looks like f30846e indirectly changed how client.IsConfigTransportTLS() works. Now it requires a version. I'll add another commit to highlight the change I'm going to make there.

[deads2k]

b03fbf9 rather.

[deads2k]

@smarterclayton The rebase required changes in pkg/client/helper.go where behavior of defaultServerUrlFor changed. You'll want to look at the last commit to see if you agree.

[zmerlynn]

Hm. This may be clutter in my home directory, but:

Project: artful-fortress-786
... in detect-minions()
Running: gcloud preview container kubectl --project=artful-fortress-786 --zone=us-central1-f --cluster=zml-gke-e2e get minions -o template -t {{range.items}}{{.id}}
{{end}}
ERROR: F0108 07:38:17.676386    3552 get.go:58] more than one authentication method found for  .  Found [authFile clientCert], only one is allowed

As a note, I previously had both GCE and GKE E2E clusters up, so it may be confused. But ... is this some sort of upgrade behavior gone awry? (Sorry, just trying to vet this for cluster creation on the GKE provider, because it's about to get enabled on Jenkins.)

[zmerlynn]

Yeah, I think this is currently failing to create clusters with the GKE provider (sorry). I removed ~/.kube* clutter from my home directory just to make sure I wasn't doing something wrong, then double checked ~/.config/gcloud/kubernetes after a go run ./hack/e2e.go -v -down to make sure we cleaned up there, and I'm still getting the above error on an attempt to -up.

[deads2k]

@zmerlynn I'm most appreciative. Do you have a .kubeconfig file? One possibility is that you have a .kubeconfig file that specifies a client cert and you're also specifying a --auth-path or you could be trying to expression both --auth-path and --client-certificate .

I think it probably makes sense for me to eliminate the restriction of a single means of identification for now, to be revisited at a later time.

[zmerlynn]

I need to disappear for the day, but perhaps @jlowdermilk or @mbforbes can help answer questions. I don't have a specific .kubeconfig file - this just a plain out-of-box config (that I tried to roll back to vanilla, but that's remarkably fidgety).

If you have Google Compute access, you should be able to run the GKE provider as well, so it's not too hard to test on your side. But yes, removing that restriction sounds wise. :)

[j3ffml]

I can take a look. Attempting to run gce/gke e2e now.

[zmerlynn]

@jlowdermilk: You may not want to assign unless you want to review the whole thing. :) I was just doing a sniff test on GKE cluster creation by taking the pull request into a local branch (since it broke GCE yesterday).

[zmerlynn]

@deads2k: FWIW, I'm totally excited for this to land finally. Looking forward to parallel configs without having to hack around it.

[j3ffml]

@zmerlynn, yup, that's intentional, I reviewed most of this already in #2861.

@deads2k, for GKE at least, the problem is what you suggested. gcloud specifies both --auth-path and --client-certificate. It does this because it is using an older template of the kubernetes_auth file that contains only "User" and "Password". We can fix that in a future release, but for now, is it reasonable to allow both authFile and clientCert and merge them in that order?

[deads2k]

@jlowdermilk I'm working on doing that now. I've got to get the different merge orders and defaulting correct. I'll have it this afternoon.

[deads2k]

@jlowdermilk Rebased, clean travis, and my hack/e2e-test.sh using the GCE provider finished clean. You should definitely take the time to review "fixes e2e failure on gce with new .kubeconfig, kick travis". The loading rules are significantly more complex that they were in #2861, but I think I've broken them down enough to be understandable.

EDIT

2015/01/08 14:52:17 Passed tests: basic.sh[1/1] certs.sh[1/1] goe2e.sh[1/1] guestbook.sh[1/1] liveness.sh[1/1] monitoring.sh[1/1] pd.sh[1/1] private.sh[1/1] services.sh[1/1] update.sh[1/1]
2015/01/08 14:52:17 Flaky tests:
2015/01/08 14:52:17 Failed tests:
2015/01/08 14:52:17 Success!
2015/01/08 14:52:17 Running: teardown
Project: openshift-gce-devel

[j3ffml]

LGTM

[smarterclayton]

Ready to try again.... :)