Closed seh closed 5 years ago
client-go version: v0.0.0-master+$Format:%h$
Aside: Urgh. Apparently reporting an actual version was broken in upstream client-go a few months after kubecfg version
started reporting it: kubernetes/client-go#568
According to vendor/vendor.json from that git tag, kubecfg 0.9.1 shipped with client-go release kubernetes-1.10.3
The "promote exec to beta" commit you cite first appeared in kubernetes 1.11.0-beta.2, so no kubecfg
0.9.1 does not include that patch. It does have an older version of the exec plugin however, but I would have to go reading diffs to understand exactly how it changed between 1.10 and 1.11.
What we need is a new kubecfg release with a newer client-go.
Do you think there's significant work in porting to a newer client-go release? I haven't been tracking how much is changing in there these days. Two years ago, it was still a bucking bronco.
It should be fairly straightforward. The usual steps are adjusting for minor API restructures, and juggling the other dependent imports until you find a combination that compiles. (The latter has become substantially easier now that there is unified release tagging across the kubernetes/* projects)
Now we'll need another release—preferably one that makes it all the way to Homebrew.
@anguslees, what steps are necessary to advance the kubecfg version available through Homebrew?
Please see Homebrew/homebrew-core#38849.
Using kubecfg version 0.9.1 on macOS, if my KUBECONFIG file uses a client-go credential plugin, kubecfg update fails with the following message:
That line appears to originate in the
exec.newAuthenticator
function. Looking at the history of that file, I wonder if kubecfg's version of client-go is old enough to predate the introduction of "client.authentication.k8s.io/v1beta1," which came in with this commit on 31 May 2018: client-go: promote exec plugin support to beta.According to the current go.mod file, our version of client-go is "v0.0.0-20180521144600-29ae1f00c3d8."
Here is the output of kubecfg version: