Anyone seeing this error after the recent update?
...
# kubernetesk
kind-fireman-33438
10/30/2023, 8:02 PMAnyone seeing this error after the recent update?
Copy code
error: an unhandled error occurred: program failed:
waiting for RPCs: failed to decode YAML: rpc error: code = Unknown desc = invocation of kubernetes:yaml:decode returned an error: failed to initialize discovery client: The gcp auth plugin has been removed.
Please use the "gke-gcloud-auth-plugin" kubectl/client-go credential plugin instead.
See <https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke> for further detailsd
dry-keyboard-94795
10/30/2023, 8:53 PMYour kubeconfig may need updating to use the new auth plugin
k
kind-fireman-33438
10/30/2023, 10:02 PMI nuked the kube config (it was old from something else and not intended to be being used and that resolved the issue. Odd becuase I didn’t want to use that config at all. Didn’t realize it waas using whatever my default tehre was. I would expect it to override it.
d
dry-keyboard-94795
10/30/2023, 10:04 PMif you specified one, it should definitely overwrite. Are you using an explicit provider? perhaps it fell back to using the default provider somewhere
k
kind-fireman-33438
11/01/2023, 2:20 PMI’m using an explicit provider which I would have imagined would override my local config. I shouldn’t have to nuke my local config to use a pulumi created provider.
d
dry-keyboard-94795
11/01/2023, 2:27 PMIt's worth adding this to your config, to prevent pulumi accidentally using the default providers:
https://www.pulumi.com/docs/concepts/config/#pulumidisable-default-providers
k
kind-fireman-33438
11/01/2023, 11:15 PMOh good call, that will help!
kind-fireman-33438
11/01/2023, 11:17 PMThe repo you linked is helpful too. Great to see how others are actually putting this in code.
kind-fireman-33438
11/09/2023, 4:51 PMIt seems even with disable default providers for kubernetes, I still have to move my ~/.kube/config file to some other name in order for the Kubeconfig: [mykubeconfigstring] param to take any effect. Is this a known issue? Or maybe I’m missing something on how to set it up.
The code is here if it helps: https://github.com/phutchins/dimo-node
Specifically the kubeProvider: https://github.com/phutchins/dimo-node/blob/main/dependencies/dependencies.go#L26
d
dry-keyboard-94795
11/09/2023, 5:15 PMIs this provider instance also failing to use the kubeconfig?
https://github.com/phutchins/dimo-node/blob/754fb1fbec83214fa516b5c7ba6b279d92d1b864/infrastructure/infrastructure.go#L258
k
kind-fireman-33438
11/09/2023, 5:15 PMNo, that one looks like it’s working just fine. Which is why I’m confused. 🙂
d
dry-keyboard-94795
11/09/2023, 5:16 PMI'm not too familiar with golang. Perhaps if BuildInfrastructurer returned the kubeconfig directly, it may work?
d
damp-airline-38442
11/09/2023, 8:25 PM@kind-fireman-33438 you might be hitting a problem related to how the
providerChartd
dry-keyboard-94795
11/09/2023, 8:30 PMOhai, @damp-airline-38442. I'm antdking :)
It looks like the provider is specified explicitly in this case, though maybe the go-sdk is less clear in explicit vs multiple providers with its DSL.
In any case, thanks for looking into the issue
k
kind-fireman-33438
11/09/2023, 8:44 PMHey @damp-airline-38442, thanks for the update. I’ll definitely keep an eye on that issue and PR.
Could it be that if you specify a provider that was given an empty string for its kubeconfig, it reverts to the default config/provider?
d
damp-airline-38442
11/09/2023, 9:05 PMI would tentatively say no that it would not fall back to a default provider. More likely that the provider isn't propagating. That said when a provider is misconfigured, it falls back to a degraded mode of behavior.