Having issues with helm charts on the latest version of the @pulumi/kubernetes package (1.4.2).
This is occurring on existing stacks and new stacks, using --skip-preview does not get around it.
$ pulumi version
v1.8.1
packages.json
{
"name": "kubernetes-typescript",
"devDependencies": {
"@types/node": "^13.1.4"
},
"dependencies": {
"@pulumi/eks": "^0.18.18",
"@pulumi/kubernetes": "^1.4.2",
"@pulumi/pulumi": "^1.8.1"
}
}
index.ts
import * as eks from "@pulumi/eks";
import * as k8s from "@pulumi/kubernetes";
const cluster = new eks.Cluster("test", {
minSize: 2,
maxSize: 5,
version: "1.14",
instanceType: "m5a.large"
});
const influx = new k8s.helm.v2.Chart(
"influxdb",
{ chart: "stable/influxdb" },
{ provider: cluster.provider }
);
Getting this error from each chart resource
Error: invocation of kubernetes:yaml:decode returned an error: unable to load Kubernetes client configuration from kubeconfig file: invalid configuration: no configuration has been provided
at monitor.invoke (/XXXXXX/infrastructure/node_modules/@pulumi/pulumi/runtime/invoke.js:172:33)
at Object.onReceiveStatus (/XXXXXX/infrastructure/node_modules/grpc/src/client_interceptors.js:1210:9)
at InterceptingListener._callNext (/XXXXXX/infrastructure/node_modules/grpc/src/client_interceptors.js:568:42)
at InterceptingListener.onReceiveStatus (/XXXXXX/infrastructure/node_modules/grpc/src/client_interceptors.js:618:8)
at callback (/XXXXXX/infrastructure/node_modules/grpc/src/client_interceptors.js:847:24)
This appears to be a problem with preview, specifically. This example works if you do pulumi up --skip-preview. Debugging the preview problem now.
Hmm, I haven't been able to reproduce on preview, either.
Can you post the versions of pulumi packages you're using, and further details on the workflow where you're seeing this problem (i.e. using existing stacks, only on new stacks, only on preview, etc.)? Thanks!
I had a similar problem with k8s.yaml.Config resources that do not use the default kubernetes provider. Reverting the kubernetes provider to 1.4.1 solved the issue for now.
The debug log looks like the following:
debug: Invoke RPC finished: tok=kubernetes:yaml:decode; err: Error: 2 UNKNOWN: invocation of kubernetes:yaml:decode returned an error: unable to load Kubernetes client configuration from kubeconfig file: context "this-is-not-the-cluster-you-re-looking-for" does not exist, resp: undefined
error: Running program '/Users/matthieu/frisson/infra' failed with an unhandled exception:
Error: invocation of kubernetes:yaml:decode returned an error: unable to load Kubernetes client configuration from kubeconfig file: context "this-is-not-the-cluster-you-re-looking-for" does not exist
at /Users/matthieu/frisson/infra/node_modules/@pulumi/pulumi/runtime/invoke.js:172:33
at Object.onReceiveStatus (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:1210:9)
at InterceptingListener._callNext (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:568:42)
at InterceptingListener.onReceiveStatus (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:618:8)
at callback (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:847:24)
The this-is-not-the-cluster-you-re-looking-for is the value of the kubernetes:context config. This is to make sure that the default kubernetes provider is never used
Ok, I've tracked down the problem now, and am working on a fix.
The error is triggered if the local context doesn't have a working k8s cluster available. Calls to the k8s provider binary using invoke were unintentionally using the default resource provider, so that's the source of the error messages.
1.4.3 release is in progress and reverts the changes causing this bug.
It looks like the error came back on 1.4.4 release:
Error: invocation of kubernetes:yaml:decode returned an error: unable to load Kubernetes client configuration from kubeconfig file: context "this-is-not-the-cluster-you-re-looking-for" does not exist
at /Users/matthieu/frisson/infra/node_modules/@pulumi/pulumi/runtime/invoke.js:172:33
at Object.onReceiveStatus (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:1210:9)
at InterceptingListener._callNext (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:568:42)
at InterceptingListener.onReceiveStatus (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:618:8)
at callback (/Users/matthieu/frisson/infra/node_modules/grpc/src/client_interceptors.js:847:24)
Reverting to 1.4.3 solved the issue for me
@mleclercq Ok, I was able to reproduce. It looks like I fixed a related error, but missed this case. Working on a fix now.
Most helpful comment
Ok, I've tracked down the problem now, and am working on a fix.
The error is triggered if the local context doesn't have a working k8s cluster available. Calls to the k8s provider binary using
invokewere unintentionally using the default resource provider, so that's the source of the error messages.