0.10.8 - Subnet IDs are case-sensitive in TF, not in Azure API

[samirageb]

When using an interpolated/constructed subnet_id reference, azure network interfaces will always report a change is required, even when there isn't one. The template provided is a working basic repro of this occurring.

Terraform Version

0.10.8
terraform-provider-azurerm_v0.3.2_x4

Affected Resource(s)

• azurerm_virtual_network_interface

Unknown if this affects other resources that reference subnet_ids

Terraform Configuration Files

variable "azure_subscription_id"        {
  default = ""
}
variable "azure_client_id"              { 
  default = ""
}
variable "azure_client_secret"          {
  default = ""
}
variable "azure_tenant_id"              { 
  default = ""
}

provider "azurerm" {
  version         = "~> 0.3"
  subscription_id = "${var.azure_subscription_id}"
  client_id       = "${var.azure_client_id}"
  client_secret   = "${var.azure_client_secret}"
  tenant_id       = "${var.azure_tenant_id}"
}

resource "azurerm_resource_group" "rg" {
  name     = "TerraformBug-Rg"
  location = "West US"
}

resource "azurerm_virtual_network" "bug" {
  name                = "TerraformBug-VNet"
  address_space       = ["10.0.0.0/16"]
  location            = "${azurerm_resource_group.rg.location}"
  resource_group_name = "${azurerm_resource_group.rg.name}"
}

resource "azurerm_subnet" "bug" {
  name                 = "BugSubnet"
  resource_group_name  = "${azurerm_resource_group.rg.name}"
  virtual_network_name = "${azurerm_virtual_network.bug.name}"
  address_prefix       = "10.0.1.0/24"
}

resource "azurerm_network_interface" "bug" {
  name                = "TerraformBug-Nic0"
  location            = "${azurerm_resource_group.rg.location}"
  resource_group_name = "${azurerm_resource_group.rg.name}"

  ip_configuration {
      name = "ipconfig"
      subnet_id = "${local.subnet_id}"
      private_ip_address_allocation = "dynamic"
  }
}

locals {
  # Final subnet ID to be referenced
  subnet_id = "/subscriptions/${var.azure_subscription_id}/resourceGroups/${azurerm_resource_group.rg.name}/providers/Microsoft.Network/virtualnetworks/${azurerm_virtual_network.bug.name}/subnets/BugSubnet"
}

Debug Output

The following output is from a clean apply, followed by a plan.
https://gist.github.com/samirageb/47924c72ba2c6165674f1122c5d1b507

Panic Output

N/A

Expected Behavior

Output would read:
No changes. Infrastructure is up-to-date.

Actual Behavior

Output actually reads:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ azurerm_network_interface.bug
      ip_configuration.0.subnet_id: "/subscriptions/***/resourceGroups/TerraformBug-Rg/providers/Microsoft.Network/virtualNetworks/TerraformBug-VNet/subnets/BugSubnet" => "/subscriptions/***/resourceGroups/TerraformBug-Rg/providers/Microsoft.Network/virtualnetworks/TerraformBug-VNet/subnets/BugSubnet"


Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. terraform plan

Important Factoids

Nothing custom.

References

None that I found

[tombuildsstuff]

Hey @samirageb

Thanks for opening this issue :)

The issue you're seeing here is that the Subnet URI's are Case Sensitive in Terraform, but are case-insensitive in Azure (however, unfortunately Azure's inconsistent in that not all API's are case-insensitive) - we can update Terraform to handle be case-insensitive for this field, however in the interim you can update the URI from virtualnetworks to virtualNetworks, which will solve the perpetual diff. e.g.

locals {
  # Final subnet ID to be referenced
  subnet_id = "/subscriptions/${var.azure_subscription_id}/resourceGroups/${azurerm_resource_group.rg.name}/providers/Microsoft.Network/virtualNetworks/${azurerm_virtual_network.bug.name}/subnets/BugSubnet"
}

FYI I'd recommend using the Subnet ID from the resource (${azurerm_subnet.bug.id}) rather than manually composing it (as it's less code and unfortunately these can change from time-to-time) - in the future we're intending to have Data Sources for Virtual Networks and Subnets too.

Thanks!

[samirageb]

@tombuildsstuff Thanks for the clarification. There's no way I would have thought this was case related. I totally understand referring to the subnetID from the resource, but in my case TF network configs are completely isolated from VM configs for security purposes, and differing lifecycles. Looking forward to the data sources though, as that would be a great workaround.

I would ask if there's anywhere that I can reference which Azure APIs are case-sensitive? Also, it seems like adding the per-api logic into the provider around case insensitivity would be a good preventative step for users as well.

[samirageb]

@tombuildsstuff Updated the title to reflect reality. Once my q's are addressed (one way or another), I'll close this issue.

[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 👉 hashibot-feedback@hashicorp.com. Thanks!