Regression in azurerm_network_interface with private_ip_address_version starting with terraform-provider-azurerm 1.21

[jpbuecken]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.11.11

• provider.azurerm v1.21.0

Affected Resource(s)

• azurerm_network_interface

Terraform Configuration Files

variable "network" {
  default = "unset"
}

variable "subnet" {
  default = "unset"
}

## azure specific ##
variable "rg_vm" {
  description = "Name of the resource group in which the vm should be placed"
}

variable "rg_net" {
  description = "Name of the resource group in which the network is located"
}

# get resource group for VMs
data "azurerm_resource_group" "rg_vm" {
  name = "${var.rg_vm}"
}

# get resource group for network
data "azurerm_resource_group" "rg_net" {
  name = "${var.rg_net}"
}

data "azurerm_subnet" "subnet" {
  name                 = "${var.subnet}"
  virtual_network_name = "${var.network}"
  resource_group_name  = "${data.azurerm_resource_group.rg_net.name}"
}

resource "azurerm_network_interface" "nic_0" {

  name                = "nic_0"
  location            = "${data.azurerm_resource_group.rg_vm.location}"
  resource_group_name = "${data.azurerm_resource_group.rg_vm.name}"

  ip_configuration {
    name                          = "ip-configuration"
    subnet_id                     = "${data.azurerm_subnet.subnet.id}"
    private_ip_address_allocation = "dynamic"
  }
#  ip_configuration {
#    name                          = "ip-configuration1"
#    subnet_id                     = "${data.azurerm_subnet.subnet.id}"
#    private_ip_address_allocation = "dynamic"
#  }

}

Expected Behavior

Assume you have created a network interface via the template above.
If I uncomment the lines for an additional IP and run a terraform apply, a second IP should be added to the interface. This worked with provider version 1.20

Actual Behavior

It want to rebuild the interface:

buec011@gtunxlvk05705:~/test/azure> terraform apply
data.azurerm_resource_group.rg_vm: Refreshing state...
data.azurerm_resource_group.rg_net: Refreshing state...
data.azurerm_subnet.subnet: Refreshing state...
azurerm_network_interface.nic_0: Refreshing state... (ID: /subscriptions/93e4d09b-a40d-4475-bf6e-...rosoft.Network/networkInterfaces/nic_0)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ azurerm_network_interface.nic_0 (new resource required)
      id:                                                                 "/subscriptions/93e4d09b-a40d-4475-bf6e-6f6e76f7b7c0/resourceGroups/asy-osoc-prod-rg-lvm/providers/Microsoft.Network/networkInterfaces/nic_0" => <computed> (forces new resource)
      applied_dns_servers.#:                                              "0" => <computed>
      dns_servers.#:                                                      "0" => <computed>
      enable_accelerated_networking:                                      "false" => "false"
      enable_ip_forwarding:                                               "false" => "false"
      internal_dns_name_label:                                            "" => <computed>
      internal_fqdn:                                                      "" => <computed>
      ip_configuration.#:                                                 "1" => "2"
      ip_configuration.0.application_gateway_backend_address_pools_ids.#: "0" => <computed>
      ip_configuration.0.application_security_group_ids.#:                "0" => <computed>
      ip_configuration.0.load_balancer_backend_address_pools_ids.#:       "0" => <computed>
      ip_configuration.0.load_balancer_inbound_nat_rules_ids.#:           "0" => <computed>
      ip_configuration.0.name:                                            "ip-configuration" => "ip-configuration"
      ip_configuration.0.primary:                                         "true" => <computed>
      ip_configuration.0.private_ip_address_allocation:                   "dynamic" => "dynamic"
      ip_configuration.0.private_ip_address_version:                      "IPv4" => "IPv4"
      ip_configuration.0.subnet_id:                                       "/subscriptions/93e4d09b-a40d-4475-bf6e-6f6e76f7b7c0/resourceGroups/asy-osoc-sha-rg-net/providers/Microsoft.Network/virtualNetworks/asy-osoc-sha-vnet/subnets/asy-osoc-sha-subnet-front" => "/subscriptions/93e4d09b-a40d-4475-bf6e-6f6e76f7b7c0/resourceGroups/asy-osoc-sha-rg-net/providers/Microsoft.Network/virtualNetworks/asy-osoc-sha-vnet/subnets/asy-osoc-sha-subnet-front"
      ip_configuration.1.application_gateway_backend_address_pools_ids.#: "" => <computed>
      ip_configuration.1.application_security_group_ids.#:                "" => <computed>
      ip_configuration.1.load_balancer_backend_address_pools_ids.#:       "" => <computed>
      ip_configuration.1.load_balancer_inbound_nat_rules_ids.#:           "" => <computed>
      ip_configuration.1.name:                                            "" => "ip-configuration1"
      ip_configuration.1.primary:                                         "" => <computed>
      ip_configuration.1.private_ip_address_allocation:                   "" => "dynamic"
      ip_configuration.1.private_ip_address_version:                      "" => "IPv4" (forces new resource)
      ip_configuration.1.subnet_id:                                       "" => "/subscriptions/93e4d09b-a40d-4475-bf6e-6f6e76f7b7c0/resourceGroups/asy-osoc-sha-rg-net/providers/Microsoft.Network/virtualNetworks/asy-osoc-sha-vnet/subnets/asy-osoc-sha-subnet-front"
      location:                                                           "westeurope" => "westeurope"
      mac_address:                                                        "" => <computed>
      name:                                                               "nic_0" => "nic_0"
      private_ip_address:                                                 "10.19.28.38" => <computed>
      private_ip_addresses.#:                                             "1" => <computed>
      resource_group_name:                                                "asy-osoc-prod-rg-lvm" => "asy-osoc-prod-rg-lvm"
      tags.%:                                                             "0" => <computed>
      virtual_machine_id:                                                 "" => <computed>


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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Steps to Reproduce

1. terraform apply
2. Add a section for an additional IP
3. terraform apply -> Forces new resource

References

I assume this is a regression by
#2548
and the commit
5b634bd

The entry ForceNew: true is wrong or should apply to azurerm_network_interface.nic_0.ip_configuration.1 and not to the whole interface!

[NilsBusche]

Possible solution

Define only the primary ip configuration within the azurerm_network_interface resource. Currently Azure does not allow you to set an IPv6 configuration as primary, so the field private_ip_address_version would be obsolete at the moment.

For adding secondary ip configurations create a new resource (e. g. azurerm_network_interface_secondary_ip_configuration or sth similar). In this resource use the same arguments as in the ip_configuration block from azurerm_network_interface (including private_ip_address_version) . Then the entry ForceNew: true makes sense because only the affected ip configuration will be redeployed.
This resource could be connected by a field network_interface_name or network_interface_id to the corresponding network interface.

[NilsBusche]

It would be great if an official developer could reply if this possible solution would be a good idea.

The actual implementation would be a next step, but if this does not make sense, we should think about another possibility to fix this bug.

[ghost]

This has been released in version 1.34.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 1.34.0"
}
# ... other configuration ...

[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!