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.

Pulumi Community

also wondering if this needs a bug report

found this <https://github.com/pulumi/pulumi/issues/4996>

suggested solution kind of sucks in my case, since the dependency tree is pretty deep

we're sorry for this experience. generally, if you use autonaming and don't provide explicit clusternames, this doesn't happen
the reason it happens when using explicit names is because the provider resource has an explicit name in it, the cluster disappears and then there's nowhere to put the the kubernetes resources

unfortunately there's not much you can do once you get into this state except repaiir your statefile :disappointed:

yeah, okay, that makes sense. i understand the issue, and generally this kind of operation isn’t the sort of thing i’d expect to do in production, just didn’t expect to blow my foot off either

so you’re suggesting that we let pulumi name the cluster (i.e. suffix it automatically?)

hopefully don’t have to do this again but probably worth versus having pretty names

Thanks for leaving a comment on <https://github.com/pulumi/pulumi/issues/4996>, Jem, and sorry you hit this. I think that with the experience you’ve described in the thread we may have enough data to repro this, which has been tricky in the past.

a little more info, the biggest clean up was helm chart objects, which even though they expressed a parent relationship to the cluster, got left behind