Hi everyone, we’re having pulumi k8s issue where we have two resources (a Kustomize directory and a Helm chart) which were created long after the cluster was provisioned using an alternative provider (ie an ambient kubeconfig login instead of the provider from the cluster resource itself). Now that were maintaining this stack, we want to use the

cluster.provider

instead, so we issued a change to use the new provider for those two resources but it attempting to create the new k8s objects which already exist in the cluster (“x already exists”). I see from the pulumi issues that changing a provider on the fly can have issues, but I don’t understand why even when we delete those resources from the state and then run a refresh, why it can’t identify that they already exist in k8s? Is it expected that

k8s.kustomize.Directory

would be able to refresh in that way?

to confirm, you have 2 resources without an explicit provider (using the default provider) and you’re trying to attach an explicit provider to them?

yes

this pulumi program was created iteratively into such a state that it wasn’t able to be deployed and destroyed from scratch, so we’re going back in to ensure it can be

sorry for the delay but this sounds like a good course of action. fwiw, you can completely disable default providers like so:

pulumi:disable-default-providers:
- kubernetes

this forces you to explicitly pass providers to all resources. personally i try to always use this for larger projects because it avoids surprises like this, and because i prefer to see dependencies injected.

oh great tip