This message was deleted.

I'm not sure that it's solid but you might want to check out this GH issue and comment https://github.com/pulumi/pulumi-kubernetes/issues/924#issuecomment-566747162. On a personal note, I had been unable to import any of my deployments/services/cronjobs etc, that were created with Helm v2. My strategy in adopting Pulumi has been to create a new resource with Pulumi and delete the old one. This is time-consuming and risk-prone since the tool does not give you the confidence that your new resource is the same as the one you're replacing. However, I recently discovered the "enable dry run" behaviour and it looks like the remainder of my resources will import. The "enable dry run" seems a very strange name. It can be enabled with the provider (as in the comment above), or using an environment variable like:

$ PULUMI_K8S_ENABLE_DRY_RUN=true pulumi --stack=production preview --diff --expect-no-changes

@average-receptionist-65239 thanks, this might be useful. I imported resources manually pushing them into the state (see messages below). Actually, I don't like the idea to import resources by modifying the code - it doesn't make any sense. The way they do it in terraform is much cleaner.

right, I don't use CRDs at all. I would have preferred to import all the resources though so that I could be sure I had the definitions lined up. Helm v2 seems to have been the culprit there.

@average-receptionist-65239 it's just a subcommand

terraform import <resource name> <resource id>

will check resource presence and add it to the stack state

How does Terraform know which HCL definition the imported resource is referring to? Does it prevent you importing if your HCL definition is different from the actual resource?