_This issue was originally opened by @DYNSOL as hashicorp/terraform#21357. It was migrated here as a result of the provider split. The original body of the issue is below._
0.11.14
1.27
resource "azurerm_subnet" "SubnetwithRouteTable" {
name = "sn-vn-${var.SubnetName}"
resource_group_name = "${var.RGName}"
virtual_network_name = "${var.vNetName}"
address_prefix = "${var.Subnetaddressprefix}"
service_endpoints = "${var.SVCEP}"
}
resource "azurerm_subnet_route_table_association" "RouteTableAssociation" {
subnet_id = "${azurerm_subnet.SubnetwithRouteTable.id}"
route_table_id = "${azurerm_route_table.RouteTable.id}"
depends_on = ["azurerm_route_table.RouteTable"]
}
resource "azurerm_route_table" "RouteTable" {
name = "rt-sn-vn-${var.RouteTableName}"
location = "${var.RTLocation}"
resource_group_name = "${var.RGName}"
disable_bgp_route_propagation = "${var.BGPDisabled}"
depends_on = ["azurerm_subnet.SubnetwithRouteTable"]
tags {
Environment = "${var.EnvironmentTag}"
}
}
Azure Subnet to be created, then Route Table and then for azurerm_subnet_route_table_association to associate the two resources.
The first time i run terraform apply it works perfectly. The second time i run apply it removes the RT associations. The third time it runs, it associates the subnet and route table again.
Hey @DYNSOL. I'm sorry to hear that you ran into this issue. It's caused by route_table_id being how we used to associate subnets and route tables. We've since moved towards azurerm_subnet_route_table_association but removing route_table_id would be a breaking change which we want to limit to major version bumps of the provider. We plan on removing it when release 2.0 of the provider in the coming months but until then you can workaround this by putting
lifecycle {
ignore_changes = ["route_table_id"]
}
in the subnet resource configuration.
This issue is very similar to yours so I'll be closing this in favor of that. Feel free to comment in the other issue if you continue to have issues or to view any updates around this.
Thanks, that worked.
@mbfrahry Seeing the same issue but with azurerm_route. Adding lifecycle { ignore_changes = ["route_table_id"]} to the subnet does not appear to resolve the issue.
Example:
resource "azurerm_resource_group" "example-rsg" {
name = "example-rsg"
location = "uksouth"
}
resource "azurerm_virtual_network" "example-vnet" {
name = "example-vnet"
location = "uksouth"
resource_group_name = "example-rsg"
address_space = ["10.0.0.0/24"]
}
resource "azurerm_subnet" "example-subnet" {
name = "example-subnet"
resource_group_name = "example-rsg"
virtual_network_name = "${azurerm_virtual_network.example-vnet.name}"
address_prefix = "10.0.0.0/24"
route_table_id = "${azurerm_route_table.example-udr.id}"
lifecycle {
ignore_changes = ["route_table_id"]
}
}
resource "azurerm_route_table" "example-udr" {
name = "example-udr"
location = "uksouth"
resource_group_name = "example-rsg"
route {
name = "default-route"
address_prefix = "0.0.0.0/0"
next_hop_type = "Internet"
}
}
resource "azurerm_subnet_route_table_association" "perimeter-subnet-association" {
subnet_id = "${azurerm_subnet.example-subnet.id}"
route_table_id = "${azurerm_route_table.example-udr.id}"
}
resource "azurerm_route" "example-route" {
name = "example-route"
resource_group_name = "example-rsg"
route_table_name = "${azurerm_route_table.example-udr.name}"
address_prefix = "192.168.0.0/24"
next_hop_type = "VirtualAppliance"
next_hop_in_ip_address = "10.0.0.1"
}
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!
Most helpful comment
Hey @DYNSOL. I'm sorry to hear that you ran into this issue. It's caused by
route_table_idbeing how we used to associate subnets and route tables. We've since moved towardsazurerm_subnet_route_table_associationbut removingroute_table_idwould be a breaking change which we want to limit to major version bumps of the provider. We plan on removing it when release 2.0 of the provider in the coming months but until then you can workaround this by puttingin the subnet resource configuration.
This issue is very similar to yours so I'll be closing this in favor of that. Feel free to comment in the other issue if you continue to have issues or to view any updates around this.