/cc @ghodss @jlowdermilk @derekwaynecarr @smarterclayton

@smarterclayton simple renames squashed in. APIServer and APIVersion captialized. CmdBuilder clarified to FlagBasedBuilder. IsReady() renamed to Complete().

@smarterclayton read path complete including merging and overriding.

@smarterclayton Comments addressed except

Remove Client() method.

It does work when you won't want to skew server and client versions. If my intent is to get a client.Client for a particular server,authInfo pair, it doesn't seem unreasonable to provide checking that the client is likely to work. Sort of a validation check before returning. Given that we already have a flag for this in both kubernetes and openshift, it seems reasonable to have a common spot to have it checked. Using the factory doesn't seem very clean. That prevents this code from standing alone and the Factory in kubectl seems only tangentially related to what this code is trying to do.

@smarterclayton moved match-server-version

minor nit on godoc, but looks good to me.

Will look later today

On Dec 17, 2014, at 3:27 PM, David Eads notifications@github.com wrote:

@smarterclayton moved match-server-version

—
Reply to this email directly or view it on GitHub.

@derekwaynecarr typo fixed.

@ghodss @jlowdermilk This enables reading multiple cli configuration profiles #1755. Do you guys have comments?

LGTM, this fits the design proposed in #1755 nicely. Just nits above.

Might be helpful to add a .md doc that includes an explanation of load order. Maybe cut/paste the text of the comment on getKubeConfig

Might be helpful to add a .md doc that includes an explanation of load order.

@jlowdermilk Just a doc under kubernetes/docs?

Some final comments (one substantial concern about validation, one gap with flag names), otherwise is in good shape to me.

@smarterclayton Got the renames. I put the error type export in a separate commit so you can confirm that's how you want it.

@smarterclayton tweaked, rebased, squashed.

LGTM

I think that this broke e2e because we didn't make changes to cluster turn up to write the appropriate config file.

I would lean towards rolling this back, and then have a re-revert with changes to kube-up function cluster/*/

Sorry!

/sub (chasing this with @brendanburns)

@brendanburns All command line flags were kept exactly the same and the file isn't supposed to be required, however vagrant e2e has always been hit or miss so I got the same results as I got on master and considered it good.

Would you like me to do the revert? Also, do you have a gist with the failure?

The e2e failure looks about like this:

�[0;32mKubernetes cluster is running.  The master is running at:

�[0;33m  https://130.211.187.55

�[0;32mThe user name and password to use is located in ~/.kubernetes_auth.�[0m

... calling validate-cluster
Project: kubernetes-jenkins
Project: kubernetes-jenkins
Running: /jenkins-master-data/jobs/kubernetes-e2e-gce/workspace/kubernetes/cluster/../cluster/gce/../../cluster/../cluster/gce/../../cluster/../cluster/gce/../../platforms/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
F0107 20:34:08.663798   22537 get.go:75] Get https://130.211.187.55/api/v1beta1/minions?namespace=default: x509: certificate signed by unknown authority
2015/01/07 20:34:08 Error running up: exit status 255
2015/01/07 20:34:08 Error starting e2e cluster. Aborting.
exit status 1

Ok, well that's pretty bad. I see the problem. .kubernetes_auth contains information for the server to identify the user and information for the client to identify the server. I lost the latter half during a refactor.

I'll put together a change to restore that and show that succeeding. I'm sorry about this.

@zmerlynn Forgive my ignorance, but is there an easy way for me to run e2e using the gke provider from outside google (getting started lists gce, but not gke)?

While there was a bug in respecting "Insecure" from a .kubernetes_auth file, that didn't affect the vagrant environment either way and I noticed that "--auth_path" is handled differently for gke depending on whether it is kubecfg of kubectl. Basically, it means that making sure auth for e2e runs properly vagrant (It did before too) doesn't mean that it will work on gke.

Alternatively, if the ~/.kubernetes_auth from your failing test had "Insecure":true, then we're golden.