https://pulumi.com logo
Join Slack
Powered by
Hello, I'm trying to setup a pulumi project where ...
# getting-started
l
Hello, I'm trying to setup a pulumi project where I have a json that has all the fields I care about for a certain resource and then I read it and use pulumi to construct the resources. If i have cloud resources that already exist and I want to import them but specify them in my json so all resources are consolidated, how would I do that? I tried pulumi import but that creates a specific URN so when I try to copy the fields into a json, it complains about an already existing resource instead of just taking the existing resource and managing it under pulumi.
s
If I'm understanding correctly, you want Pulumi to read from a JSON file that contains both new and existing resources, then create what's needed and import what already exists? Am I understanding correctly? If so, I'm not sure that's possible.
l
@salmon-account-74572 hey yeah a bit confusing but I found a workaround. The biggest painpoint for my team right now is importing. We do a bulk import and it hands the code of all the resources that are imported. Now if I wanted to make a template out of the code such that we have a config file in json that represents all this, then thats the hard part. Having 100+ resources all as separate variable instances is not super manageable. Any best practices to follow?
s
You could templatize the generated code and then use it (with 
pulumi new
) to create new projects/stacks with the same set of resources. I'm not so sure about doing it the other way around.
s
Tyrone I've been doing what you have been doing, which is importing and then generalizing into reusable functions
I've been breaking it off once resource type at a time and putting them each into their own file
I then made a struct for each resource that contains all the arguments I need to run the function
build a list of those structs, then for loop it bb
I basically play whack-a-mole with the diffs for a while until I get "N unchanged", go celebrate, and then come back for the next resource type
one thing to keep in mind is that there is a major difference between a resource and the resourceArgs that are used to build it. The resource is immutable and read only once it is built, but the resourceArgs you can change.
this is real important when importing an environment because you will find resources that have typos or are put in the wrong group or whatever. They were all built by hand so mistakes will happen
so build the ResourceArgs with your most common settings, then put in all your one off logic, and then finally return the completed resource
l
yep I've done exactly what you've described! Quite a lot of work! Would love to see this as a main feature.
s
We'd love for you to create an issue in https://github.com/pulumi/pulumi to request this feature/functionality.
2 Views
Open in Slack
PreviousNext
Powered by