If you have an app and create a VPC and later chan...
# aws
b
If you have an app and create a VPC and later change the VPC and your infra depends on this VPC, then you may have some problems, you may in fact enter in a kind of pulumi hell. Meaning that pulumi can’t up or destroy. You have to delete the infra by hand, looking for depedencies between vpc’s, elb’s, eni’s and so on. That would be cool if pulumi could help and protect from this…
b
just to make sure I'm understanding - someone changed the VPC outside of Pulumi?
b
No it’s in the code
m
Can you explain more about your projects/stacks? You had one project that created a VPC, and then another that modified it, then the project that originally created it tried to modify it but gets confused because the state has been changed by another project?
b
No it’s in the same project/stack. The code was creating a VPC. A new version modified this VPC (from a newly created one to the default one). The code was pushed and triggered CI/CD which ran pulumi and then up failed and we arrive at the situation I indicate above
s
I had something similar happen yesterday in trying to update a targetgroup to use HTTPS where I did
pulumi up
to generate the change but pulumi could not destroy the resource and make the change because it was connected to a listener. I had assumed pulumi would bring down any related infra first if necessary. I got stuck where I couldn’t
pulumi destroy
the stack either and had to go through manually to take down listener first, which then allowed
pulumi destroy
to work.
b
Pulumi can't derive dependencies outside its statefile. What created the listener?
s
pulumi - this is all happening in the same stack
The change was an attempt to update the main protocol arg as well as the protocol arg within the health_check.