Specify Update and Destroy ordering

Given the current configuration

resource aviatrix_gateway gw {
  gw_name = "name"
  enable_tgw_connections = true
}

resource aviatrix_tgw_gateway_connection conn {
  gw_name = aviatrix_gateway.gw.gw_name
  tgw_name = aws_tgw.tgw.name
}

I want to delete the tgw_gateway_connection and update enable_tgw_connections to false in the same apply. The catch is that setting enable_tgw_connections to false when there is a connection still living will fail. Is there a way to force terraform to destroy the connection resource before updating the gateway resource?

Example plan

Updated:
resource aviatrix_gateway gw {
  gw_name = "name"
  enable_tgw_connections = true -> false
}
Destroyed:
- resource aviatrix_tgw_gateway_connection conn {
  - gw_name = aviatrix_gateway.gw.gw_name
  - tgw_name = aws_tgw.tgw.name
}

Hi @CyrusJavan

I think you have uncovered a bug! Providers or their platforms they service don’t often have mandatory dependencies like this, or if they do it’s in the opposite direction (normally it would be something like registering aviatrix_tgw_gateway_connection.conn within aviatrix_gateway.gw), which may explain why this hasn’t come up recently.

There’s some info about resource destruction laid out in Terraform Core Resource Destruction Notes, and the diagram I’m thinking of specifically is the second example under Resource Replacement:

While that is showing an example of replacement with an update, you can see I even added the implied edge in the diagram showing that the update depends on the destroy completion. Changing this to a destroy operation by removing the (A create) node from that graph should leave the update depending directly on the destroy.

Since this is something that actually never worked in Terraform, it’s going to take a little time to implement and verify that there are no unexpected side effects, though from the design principals noted in the documents above, the order should work as you expect.

To ensure this change applies cleanly with current versions of Terraform, it is unfortunately going to take multiple apply steps to accomplish for the time being.

There is however an unreliable way to do it. I don’t like to recommend it, but as long as you’re willing to accept an arbitrary delay and the possibility that it may still fail. You can have the aviatrix_gateway.gw resource depend on another resource’s replacement that adds a delay, which could just be a local-exec provisioner with a sleep.

Thanks!

Thanks for the detailed response @jbardin!

So from my understanding the logic is currently that if resource B depends on resource A, then resource B always waits for any modifications of resource A (update/create/replace) before going through with it’s own modifications. However, what should happen is that in the case of destroying resource B and updating resource A, then resource B should go through it’s destroy before resource A updates.

Edit: Should I open a GH issue for this? Would that make it easier to track for you all?

I opened Graph missing dependency from resource update to resource destroy · Issue #28150 · hashicorp/terraform · GitHub to track the issue. Thanks again!