auth: reregister auth providers

[mikedanese]

Alternatively we can register this in the mains of most (or all) components.

Fixes GKE e2es
Fixes: 5d721bf

That PR unregistered auth providers for kubectl and probably elsewhere.

NONE

[mikedanese]

/retest

[lavalamp]

Import where it's needed, not here.

[lavalamp]

So, yeah, in the mains of the components that need it.

[liggitt]

Or from the code that constructs auth providers. Not sure we want non-uniform handling of auth providers from loaded kubeconfig files using client-go

[mikedanese]

Our options are in the mains like we have here or in "k8s.io/client-go/rest" which actually retrieves the transport.

[liggitt]

Where we build the auth providers from the config would make the most sense to me.

[mikedanese]

@liggitt in "k8s.io/client-go/tools/clientcmd"?

[mikedanese]

@liggitt wants consistent handling of kubeconfig so he's recommending registering auth providers in clientcmd. Binaries can still construct raw rest.Configs and not import the auth providers.

[mikedanese]

/test pull-kubernetes-e2e-gke

[mikedanese]

@liggitt moving this to clientcmd adds a ton of dependencies to staging repos. Is this better than registering auth providers in mains?

[liggitt]

All of those dependencies already exist in client-go, and were pulled down on clone, right? The listing in godep files is annoying, but I don't actually think it bothers me that much. @lavalamp and @deads2k can weigh in.

I keep coming back to when I would want kubeconfig loading via clientcmd to behave inconsistently, and I can't think of a time I'd want that.

[soltysh]

/lgtm

[deads2k]

All of those dependencies already exist in client-go, and were pulled down on clone, right? The listing in godep files is annoying, but I don't actually think it bothers me that much. @lavalamp and @deads2k can weigh in.

That depends on how your vendoring tool worked. Ones like glide walk packages back to find repo dependencies. As an example, before this pull, depending on clientcmd would not pull in azure. Now it would. Pulling in azure brings with it the risk of conflicting levels of dependencies. Because we (and many other libraries) leak dependent packages through their interfaces, you have to vendor with "strip-vendor". Doing that with conflicting levels of Azure (or its transitives) produces a vendoring mess that can make it impossible to use the library.

The short version is that golang dependency management is a mess and this makes it noticeably worse. I don't like any of the options. Does anyone want to make a case for why someone who didn't care about the plugin should be forced to resolve conflicting level problems?

[liggitt]

The short version is that golang dependency management is a mess and this makes it noticeably worse.

Ok. We can just register in kubectl for now. Long-term, the externalized exec auth provider will be recommended, and could conceivably be added by default, since it likely has a much smaller dependency impact.

That PR unregistered auth providers for kubectl and probably elsewhere.

only kubectl packages imported that client, so I'd only expect that command to have been affected

[liggitt]

/lgtm
/hold for gke test

Unhold at will

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, mikedanese, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cmd/kubectl/OWNERS [liggitt,mikedanese]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mikedanese]

/test pull-kubernetes-e2e-gke

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[mikedanese]

/retest

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.