azurerm_route_table/Subnet association is dropped on update.

[hashibot]

This issue was originally opened by @TStraub-rms as hashicorp/terraform#11226. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

terraform version 0.8.4

Affected Resource(s)

• azurerm_route_table

Terraform Configuration Files

variable "tenant_id" {}
variable "client_id" {}
variable "client_secret" {}
variable "subscription_id" {}
variable "location" {}
variable "module_name" {}
variable "vnet_address_space" {}
variable "stack_subnet1" {}
variable "tags" {
  description = "(Optional) Tags to be assigned to every resource in the module."
  type        = "map"
  default     = {}
}

provider "azurerm" {
  tenant_id       = "${var.tenant_id}"
  subscription_id = "${var.subscription_id}"
  client_id       = "${var.client_id}"
  client_secret   = "${var.client_secret}"
}

resource "azurerm_resource_group" "module" {
  name     = "${var.module_name}-Network-Infrastructure"
  location = "${var.location}"
  tags     = "${var.tags}"
}

resource "azurerm_virtual_network" "module" {
  name                = "${var.module_name}-Vnet1"
  resource_group_name = "${azurerm_resource_group.module.name}"
  address_space       = ["${var.vnet_address_space}"]
  location            = "${var.location}"
  tags                = "${var.tags}"
}

resource "azurerm_subnet" "subnet1" {
  name                 = "${var.module_name}-SubNet1"
  resource_group_name  = "${azurerm_resource_group.module.name}"
  virtual_network_name = "${azurerm_virtual_network.module.name}"
  address_prefix       = "${var.stack_subnet1}"
  route_table_id       = "${azurerm_route_table.module.id}"
}

resource "azurerm_route_table" "module" {
  name                = "${var.module_name}-RouteTable"
  location            = "${var.location}"
  resource_group_name = "${azurerm_resource_group.module.name}"
  tags                = "${var.tags}"
}

resource "azurerm_route" "route_a" {
  name                = "Test Route A"
  resource_group_name = "${azurerm_resource_group.module.name}"
  route_table_name    = "${azurerm_route_table.module.name}"

  address_prefix         = "10.100.0.0/14"
  next_hop_type          = "VirtualAppliance"
  next_hop_in_ip_address = "10.10.1.1"
}

Expected Behavior

Updating the route table should keep or update the subnet association of the table.

Actual Behavior

The initial terraform apply will create all the resources without an issue.

When updating the route table (by updating the tags for instance), the subnet association is dropped.

Steps to Reproduce

1. terraform apply a route table with at least one route.
2. update the module to include new or different tags.
3. 'terraform plan` will show the only modification was the tag updates.
4. terraform apply will update the tags, but remove the subnet association from the route table.

[sebastus]

After staring at this for a while, I think I see a root issue that, if fixed, may resolve other issues. I applied the above HCL and then added a tag and re-applied. The plan output I see is this:

  ~ azurerm_resource_group.module
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

  ~ azurerm_route_table.module
      route.#:                "1" => "0"
      route.0.address_prefix: "10.100.0.0/14" => ""
      route.0.name:           "Test Route A" => ""
      route.0.next_hop_type:  "VirtualAppliance" => ""
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

  ~ azurerm_virtual_network.module
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

So - the azurerm_route_table resource is detecting route properties getting nulled out. But that's not what happened since those properties weren't populated in the original azurerm_route_table, but were added as a route resource independently.

This might be terraform core??

[mbfrahry]

I'd be interested in seeing the tffile you used to generate this but based on what you said this looks like standard terraform behavior. If the route_table did not have any routes specified in the tf file than a route was added outside of Terraform, Terraform would see this as a resource out of state with what is in the tf file and remove the conflicting route.

If default routes are added when you create a route_table then this is a bug for the provider and we can set route_table.route to computed and that should fix this issue. Does that make sense or am I reading this wrong?

[sebastus]

There are two resources: azurerm_route_table and azurerm_route. azurerm_route_table MAY have an embedded list of route but in the test case it doesn't. The HCL used is pasted above in the thread opener. No resources were added/deleted/updated outside of TF.

On the first run of tf apply: (HCL posted above)

• create 1 azurerm_route_table with no route embedded.
• create 1 azurerm_route as a distinct resource, but references the azurerm_route_table

Modify the HCL - add a tag. Second run of tf apply:

• results in the output I pasted above.
• output suggests that TF believes that the route was initially embedded in the azurerm_route_table

The output should look something like this:

~ azurerm_resource_group.module
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

  ~ azurerm_route_table.module
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

  ~ azurerm_virtual_network.module
      tags.%:                 "1" => "2"
      tags.anotherOne:        "" => "value"

[mbfrahry]

So it looks like we should make azurerm_route_table.route computed. You may not be linking azurerm_route to the azurerm_route_table declaration but the provider does look through all routes associated with a route table and adds them to the state file. This function is being called to loop through those routes.

[sebastus]

That worked. Thanks for the assist.

[mbfrahry]

Woo! Glad it worked out

[mbfrahry]

This issue is fixed in #450

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!