I'm trying to apply a Pulumi update that replaces ...
# aws
g
I'm trying to apply a Pulumi update that replaces a security group in AWS. Pulumi first tries to delete the security group before creating the replacement, however, the old security group is still in use and so AWS prevents the deletion (and Pulumi just hangs). How are folks orchestrating this kind of change?
Reading a little more about this... I do NOT have
delete_before_replace=True
set so I would expect Pulumi to create the new security group first, update the resources using the security group and then delete the old one.
l
That would work in most cases, but there's plenty of places where the security group is in use in some way that Pulumi can't detect. For example, the dependency is via a string that's build up to have to the same value as its ARN, without actually being the Output from the security group object.
A very common cause of this sort of problem is that the Pulumi name of the object is changing
This one cannot be worked around.
In general, you need to design around this. There are plenty of options.
g
OK yeah I was just going through and seeing if there was anywhere that I need to explicitly add
depends_on
l
You could change what you're changing in the security group to not require a replacement. For example, going from internal rules to attach rules means prevents this problem in the future (but not this first time).
g
It looks like they're all outputs but I need to debug a bit further
l
In your
pulumi preview
it'll say why it is deciding to delete the SG. What is the reason?
g
I'm moving some things to a new VPC so probably that but let me check
yeah:
Copy code
[diff: ~vpcId]
g
Oh I had not seen that - thank you!
l
The best solution for this particular problem, in my experience, is also by far the most awkward. You may need an interim state where you have to duplicate some resources. That is, you project may need to know about VPC1 and VPC2, and some of the resources in both. And you may need to change the code to point old things at new things, And so on. However, if you're moving all your resources to a new VPC, then it's likely that simply destroying the entire stack in the old VPC and creating it again in the new VPC is the way to go.
g
Yeah, thanks, I think I'll probably just destroy everything except the databases and then recreate everything
l
(I just hope you don't have peering set up on the old VPC.. that adds many tonnes of problems to the effort...)
g
I do not but peering will be setup on the new VPC
l
Ok, well don't do that until you've fully migrated! Peering is a real headache via IaC.
g
Thanks a lot - appreciate the help!