This message was deleted.

Although I haven’t tried it, I would think it’s possible. I think the tricky part will be figuring out what to specify for the ID required for the

import

option (https://www.pulumi.com/docs/intro/concepts/programming-model/#import) I’m guessing that you may be able to use a get function for the given type of resource to get the information needed for the import option. And then there’s the matter of “removing” the import option after the fact for the stack resource after it’s been imported. This does beg the question as to whether or not it’s possible to avoid the situation in the first place - i.e. avoid having to import existing resources on the fly. Maybe you have a bulk import event initially and then manage things via pulumi going forward. In this context, the CLI

import

option maybe useful. An example of which can be found for each API reference resource such as here: https://www.pulumi.com/docs/reference/pkg/aws/ec2/instance/#import The CLI import will also generate the code for the resource.

Does this work with a dynamic provider?

Does what work with a dynamic provider? I kinda threw out a few thoughts in my response. 🙂

Does the pulumi import CLI support generating code for/importing resources using a dynamic provider?

Not really. The CLI import actually imports the resource into the given stack and generates code that you can then add to your pulumi project code to allow you to manage the resource going forward.

So I would have to write a full fledged go provider for that approach to work. Is there any approach you could suggest that would work with a dynamic provider?

Well, now I’m wondering if I misunderstood the use-case. If you are creating a dynamic provider, then by definition the resources for which your provider exposes CRUD operations are managed like any other resources managed by off-the-shelf providers. So if your dynamic provider is finding an existing entity or creating a new entity is basically unknown by Pulumi and would be managed in your dynamic provider. Or am I still misunderstanding the use-case?

No, sounds like you are understanding. Basically I want to make my dynamic provider support upsert. If it finds a resource with a matching name, use that and update, otherwise create a new resource in the remote cloud.