https://pulumi.com logo
Join Slack
Powered by
I have a problem delete-recreating resources throu...
# general
l
I have a problem delete-recreating resources through dependencies. I'm wondering if I need to do something manually to work around this. I have an AWS ALB target group that is being renamed (the actual AWS resource, not the record in Pulumi state). So it must be deleted and recreated. The TG is in use in an ECS Service. In state, I can see the dependency in the Service, pointing at the correct TG. When I run 
pulumi up
with the code that changes the TG's name, the Service is delete-recreated, then the TG is deleted. and that fails because the (new) Service is using the TG. What is needed to ensure that Pulumi doesn't attempt to recreate the Service until after the TG has been delete-recreated?
I've just checked the AWS console: the Service has actually been deleted and not recreated. So it looks like Pulumi tried to do the right thing. Maybe the TG only thinks it's still in use? I don't know why the Service is still in state though...
Yes, the TG is still in use: there's a load balancer rule still referring to it. However, there is a correct dependency from the TG to the target group, so when the target group is to be deleted, Pulumi should try to delete the rule first, right? But there's no attempt to delete the rule.
Summary of current situation: when trying to rename a target group that has two resources dependent on it, Pulumi is correctly deleting one resource (the Service) but not the other (the ListenerRule).
Related question: is there a way to see a graph of dependencies, rather than parent-child? I know there is a feature that allows searching by dependencies, but it's not enabled in this organization 😞
Small update: the ListenerRule is showing as updating in 
pulumi preview
, presumably because the TG is changing: maybe this is confusing Pulumi, and the necessary update is somehow overwriting the necessary delete-replace?
Here's a public gist demonstrating the problem. https://gist.github.com/tenwit/33854b6e68418078443cb5230eb71fb1 Update the values on lines 3 and 4 to ones for your VPC, run 
pulumi up
, change the name on line 12, then run 
pulumi up
again. You'll get this sort of error:
Copy code
error deleting Target Group: ResourceInUse: Target group 'arn:aws:elasticloadbalancing:region:account:targetgroup/default/id' is currently in use by a listener or a rule
The preview shows this:
Copy code
+-  ├─ aws:alb:TargetGroup   default           replace     [diff: ~name]
 ~   ├─ aws:alb:Listener      listener          update      [diff: ~defaultActions]
 ~   └─ aws:alb:ListenerRule  rule              update      [diff: ~actions]
But it needs to delete-replace the ListenerRule.
b
I have had this come up multiple times in here, and never actually been able to repro it. Do you have a repro with a few lines so I can try figure out how to resolve it?
l
There's a gist linked above
b
okay, let me have a look
@little-cartoon-10569 any reason you’re not using autonaming here?
l
It's the code I've got to work with 🙂
I took a shortcut when creating the gist, so the problem is actually happening twice: the default action causes the same problem.
I "own" the code now, so I'm happy to change to autonaming. But resource name is also changing, so I'm not sure it'll help.
I'm adding an alias though.. 🤔
b
🙂 if you use autonaming this doesn’t happen at all, the explicit name seems to be the problem here. I think you’re gonna have to do some manual stuff here if you use explicit naming
l
With autonaming, does changing the resource name not cause the same problem? Or does the generated name keep the old resource name prefix?
b
hang on
l
Seems like I can't switch to autonaming without hitting this problem, anyway. Need to resolve it first, and switch to autonaming at the same time.
b
why is the lifecycle of target groups to delete before replace?
🤔
l
I think it's just changing the name that does that... is it not?
Yea, just the name.
b
no, it should create a new target group first, point all the resources to it, then delete the old one. that doesn’t appear to be happening
l
Oh. Ok. That would be good to try. Can I force that?
Oh wow.. 
deleteBeforeReplace: false
worked!
And I switched to autonaming at the same time.
Okay, demo has proved successful. I'll try in the real code.
b
well that’s the default behaviour, or it should be. especially with autonaming. but it doesn’t seem to be for this resource, which I cannot explain
l
I'd be interested to hear the explanation if you find anyone who knows it. Either way, I'm going to make the equivalent change in the real code and see how it goes. Thanks for your help again!
b
looks like we somehow disable the 
deleteBeforeReplace
behaviour is you explicitly set the name, which is new to me
but I’m glad setting it to false allows you to switch to autonaming!
Open in Slack
PreviousNext
Powered by