https://pulumi.com
Join Slack
Menu
Home
Archive
This message was deleted.
# general
s
This message was deleted.
✅ 1
b
you can remove it from the state using 
pulumi state delete <urn>
g
Is there a way to do that in the code so it doesn't impose a workflow burden? If not, is there a better design we can implement to avoid this problem? Like segregating such imports into their own stack
g
If you just need to reference an existing resource, you can get it rather than import it.
💡 1
That lets you use properties from it, but Pulumi doesn't assume ownership of it, so your destroy would leave it alone.
Every resource in Pulumi has a 
.get()
function that lets you get a resource by its id.
g
Perhaps we can 
get
the resources for now, and revise the gets to imports when we're ready to transition ownership of the resources to the new account
g
Yep, 
get
sounds like what you actually want for now.
g
My concern: would we still be able to fully describe the 
gotten
resources like we can when we 
import
?
g
you cannot modify (or destroy) resources via 
.get
, but you can reference all the properties from them.
g
💯 , that's it. Thanks y'all!
👍 1
g
You're welcome.
g
@gentle-diamond-70147 it appears that 
get()
succeeds even when the resource attributes in code don't match the gotten cloud resource, and then the code is out of sync with the pulumi resource (which matches the cloud resource). Is this a bug? cc @gentle-account-13294 who discovered this issue
👍 1
g
I might still be missing what you're trying to achieve. Can you share your code?
A resource from a 
.get()
function is essentially a read-only view of an existing resource, so I'm confused by you trying to match it in code.
g
This succeeds:
Copy code
aws.glue.CatalogDatabase.get(
    id="...",
    resource_name="...",
    name="...",
    location_uri="<s3://wrong-url>",
)
Are the non-
id
attributes ignored when 
get()
executes?
A resource from a 
.get()
 function is essentially a read-only view of an existing resource, so I'm confused by you trying to match it in code.
Even though it's read-only, we want the code to match the resource 1:1, because at some point we'll convert it from a 
get()
to a normal resource under pulumi's management.
Either now or later we can fully specify the resource attributes. Should we wait until we actually import the resource?
Perhaps given how 
get()
works we'll need to approximately 1:1 describe the resource now, and correct any mistakes that arise later when we import it?
g
Yea, I don't think 
get()
was designed with that idea in mind (specifically trying to match what the "shape" of the resource like 
import
), so I think your last point of "approximately 1:1" will be the best thing to do for now.
👍 1
1697 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by