From a DM with @billowy-army-68599. recording here for the #general channel’s sake: I’m asking for a feature that says don’t destroy/create this resource for X amount of time. Preferably this delay would only start after it’s dependents have been destroyed. I need, say the ALB controller, to delete all Loadbalancers before the controller is itslef deleted. Pulumi doesn’t know to wait for that A delay would destroy the ingresses who are dependent on the ALB controller, then the ALB controller should be given say an extra 1m to delete the LB’s, and only then should Pulumi delete the controller. Does this make sense? Lee’s Reply: it makes sense, yes. this isn’t possible though [9:27 PM] you can do some stuff inside an apply on create, and do a sleep if needed [9:28 PM] but not for a delete My reply: • Would this be worthy of a github issues? • [9:30 PM]  does it make sense that it is currently impossible to guarantee, bec of  a race condition, that the LB’s would be deleted before the controller? [9:31 PM] Currently, the only way might be to have 2 separate deployments, so one to destroy the ingresses, and then one to destroy the controller [9:33 PM] someone in a thread mentioned using traefik as a controller. Have you used this before? He mentioned this uses CRD’s and that they get correctly awaited Lee’s Reply: it’s not worthy of a github issue I’m afraid, it’s a subtlety in the way the alb load baancer controller works. creating a new load balancer for each ingress, and there’s no await ability on the status I’m afraid, especially with a delete. [9:36 PM] i personally stick with the nginx ingress controller and a single elb

@billowy-army-68599 Do you have gist/repo that has an example of the nginx controller?

take a look at the

index

and

TraefikRoute

the problem is the k8s ingress resource. specifically the new versions (as far as i can tell)

If a fix could be implemented for the ALB ctl to detect the underlying AWS resources, perhaps the route53 records created by external-dns could also be awaited. Not sure if pulumi could have this kind of visability.

I would recommend taking a look at the flow of adding a new resource, observe how it works, and it'll quickly make sense why this happens. Let's say provision an ingress with ALB controller. The operation is: • alb controller see the ingress API has a new resource • alb controller creates backing target groups etc When you do a delete/destroy of the helm chart, the process is • pulumi deletes the ingress • pulumi waits until the ingress is deleted, then when it succeeds, it deletes the controller pod that reconciled the ingress The correct Kubernetes wait to deal with these is using finalizers. If you have finalizers on the ingress resource, this wouldn't happen

i hope that helps, I'm not sure of a better way to explain it

It seems the best solution for now is to do 2 separate deployments. One to destroy the ingresses. And then to destroy the controllers

This issue describes a lot of what we are saying here: https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/1629