This message was deleted.
# general
s
This message was deleted.
a
If anyone has thoughts on how to handle this that would be great.
Is there any way to access at runtime whether a given resource has already been created in the Pulumi state for the current project and stack?
@white-balloon-205 do you happen to have some insight on this?
l
Are you removing the
import
opt after it's imported?
a
So, I'm setting the
import_
attribute in a conditional so that the intent is that it will only run once, but the conditional that I'm using doesn't toggle properly since the tag I am filtering on doesn't get applied. The relevant code is here https://github.com/mitodl/ol-infrastructure/blob/main/src/ol_infrastructure/lib/aws/ec2_helper.py#L124-L129
That's why I'm hoping to peek into the Pulumi state to include in the conditional so that the
import_
attribute doesn't get applied after the fact.
l
Usually the import is deleted from code after the import is successful. I've imported lots of things this way and never had the issue you describe. Maybe try that with one resource and see if it fixes it; if it does, you may have some extra insight or could raise an issue.
a
The reason I'm using this approach is because I'm embedding the imports in a component resource to create a full VPC, so that if a VPC already exists with the specified values (mostly CIDR block) then the relevant resources will be imported automatically.
That way I can incrementally adopt existing VPCs
l
I understand. It sounds like a good approach. I'm just wondering if that's making things complicated under the hood, and Pulumi is getting confused. If you make an experiment project or edit one snippet to not work this way, would it help you uncover the cause?
a
If I bypass the import then the already imported resources get updated as expected. My issue is that I just want to be able to examine the current state information to determine if a given resource is already managed with Pulumi.
l
Ah. You can do that using
pulumi state export --file state.json
.