Terraform-provider-azurerm: Azure RM Route Table Association - Add and Changes resource every apply.

Created on 19 May 2019  ·  4Comments  ·  Source: terraform-providers/terraform-provider-azurerm

_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._


Terraform Version

 0.11.14

Azure RM Provider Version

 1.27

Terraform Configuration Files

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}"    
    }
}

Expected Behavior

Azure Subnet to be created, then Route Table and then for azurerm_subnet_route_table_association to associate the two resources.

Actual Behavior

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.

Most helpful comment

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.

All 4 comments

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"
}
  • First-time plan + apply works as expected.
  • Second plan sets the azurerm_route.example-route for destroy.
  • Tested on azurerm v1.30.

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!

Was this page helpful?
0 / 5 - 0 ratings