Terraform-provider-azurerm: Adding address space to a peered vnet fails in-place update

[markjgardner]

Terraform Version

Terraform v0.11.2

• provider.azurerm v1.1.1

Affected Resource(s)

• azurerm_virtual_network

Terraform Configuration Files

main.tf

variable "name" {
  type = "string"
}

variable "location" {
  type = "string"
}

variable "addressspace" {
  type = "list"
}

variable "addressspace2" {
  type = "list"
}

provider "azurerm" {
  version         = "~> 1.1"
  subscription_id = "###"
  client_id       = "###"
  client_secret   = "###"
  tenant_id       = "###"
}

resource "azurerm_resource_group" "rg" {
  name     = "${var.name}-rg"
  location = "${var.location}"
}

resource "azurerm_virtual_network" "vnet1" {
  name                = "${var.name}1-vn"
  resource_group_name = "${azurerm_resource_group.rg.name}"
  address_space       = "${var.addressspace}"
  location            = "${var.location}"
}

resource "azurerm_virtual_network" "vnet2" {
  name                = "${var.name}2-vn"
  resource_group_name = "${azurerm_resource_group.rg.name}"
  address_space       = "${var.addressspace2}"
  location            = "${var.location}"
}

resource "azurerm_virtual_network_peering" "vnpeer" {
  name                      = "peervnet"
  resource_group_name       = "${azurerm_resource_group.rg.name}"
  virtual_network_name      = "${azurerm_virtual_network.vnet1.name}"
  remote_virtual_network_id = "${azurerm_virtual_network.vnet2.id}"
}

first.tfvars

name = "peertest"
location = "eastus"
addressspace = ["10.1.0.0/20"]
addressspace2 = ["10.2.0.0/20"]

second.tfvars

name = "peertest"
location = "eastus"
addressspace = ["10.1.0.0/20", "10.1.16.0/20"]
addressspace2 = ["10.2.0.0/20"]

Debug Output

https://gist.github.com/markjgardner/2c9124ce2ebb33df6cde37ddd7bedf35

Panic Output

n/a

Expected Behavior

The change should have been identified as forcing a new resource and the vnet should have been dropped and recreated.

Alternatively, if this change needs to be an in-place update of an existing resource, the peering should be dropped, the new address space added and then the peering re-enabled.

Actual Behavior

Terraform identified the change as an update to the existing resource but threw an error during the apply due to the existing peering relationship between the vnets.

Steps to Reproduce

1. terraform apply -var-file="first.tfvars"
2. terraform apply -var-file="second.tfvars"

Important Factoids

none

References

none found

[pixelicous]

Almost any change to vnets/subnets fail.. lots of issues where terraform cannot detach, reattach or rename resources

[markjgardner]

Agreed. I found another one last week where changing an established/connected vnet peering fails because it doesn't know to drop/recreate the sibling peer in the remote vnet. Azure won't let terraform recreate the target peering because the remote peer is in a disconnected state. You have to manually drop the remote before it will succeed.

[pixelicous]

it is many many resources which are items nested in other items, terraform cant do that job of recreating it..

[pearcec]

I am not sure this is possible with terraform. I would need advice from the maintainer about implementation. Networking peering is handled as a separate resource. I am not sure if terraform can access or taint a resource outside the its own.

I don't think changing the schema will help either. If you moved the peering config to the vnet it would create a circular dependency or only one of the vnets would have the vnet peering config resulting the the same issue on one side of the pair.