https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
c
@full-dress-10026 that’s saying that you’re not pointed at a kubeconfig file.
You need either to use 
stack export
to write the kubeconfig file to a place where we can pick it up automatically, or you need to use a first-class provider, as we do in the examples.
you should not need to “set” the config.
f
What is a "first-class" provider? My code looks just like the example.
c
Copy code
const k8sProvider = new k8s.Provider("k8s", {kubeconfig: cluster.kubeconfig.apply(JSON.stringify)});

const kafkaChart = new k8s.helm.v2.Chart("kafka", {
    path: "../cp-helm-charts",
    namespace: "kafka",
}, {providers: {kubernetes: k8sProvider}});
It’s the 
k8sProvider
here.
you can make one or use the one exported by the EKS library
f
Ok, I don't a 
Provider
in my code. I pass 
eksCluster.provider
to all my k8s components.
c
that shoudl work.
that error says you’re not passing the kubeconfig in.
so something is wrong.
f
Why would it think I should pass in a kubeconfig?
c
You can’t talk to a kube cluster without that information.
a provider is a thin wrapper around kubeconfig files.
YOu are passing one in with the provider, or you’re picking it up ambiently. One of those two things is true.
f
Oh I see. There was one service that did not have it set. After setting it, however, I receive these:
Copy code
kubernetes:core:Service (app-ions-service):
    error: Plan apply failed: services "app-ions-service" already exists
Guessing I need to recreate the service for some reason?
c
that is saying it already exists
so you already created it somehow.
f
Yes - the service has already been `pulumi up`'ed. I switched computers today. My previous computer must've had a kubeconfig set up in .kube.
c
that is quite likely, yes.
f
So, I added in the 
{provider: k8sProvider}
to an existing 
Service
, resulting in the above.
c
yes, but in general we can’t tell whether you’re pointed at the same cluster or not.
like, in the kubeconfig you’re given a URI or IP address that’s the location and auth info — neither of those need be unique to a cluster.
So if you created a resource on the cluster from another computer somehow, and you now point it at the same cluster, there’s no way in general to know they’re actually the same resource on the same cluster.
f
I see. Is there a way to tell Pulumi that this is the same cluster as before? Or does it make more sense to just assign a new 
name
to the Deployment and let it recreate it.
c
Nope.
If it’s a service, I’d just delete it .
and then run 
pulumi up
in the ether there is an issue about this in the kubernetes/kubernetes repository, but somehow having a unique ID for a cluster is a controversial idea. 🙂
f
That works for this case because it's a dev environment. If this was in production, that wouldn't work. How would you ensure uptime in the case that you forgot to pass an explicit 
provider
?
c
you’d probably use importers, once they are implemented.
you could also rename the service, create that, and then delete the old one out of band.
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by