terraform-provider-azurerm icon indicating copy to clipboard operation
terraform-provider-azurerm copied to clipboard

azuererm_virtual_network recreates subnet made and destroyed by azurerm_subnet

Open csorzi opened this issue 3 years ago • 5 comments

Is there an existing issue for this?

  • [X] I have searched the existing issues

Community Note

  • Please vote on this issue by adding a :thumbsup: 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 Version

1.1.8

AzureRM Provider Version

3.1.0

Affected Resource(s)/Data Source(s)

azurerm_virtual_network, azurerm_subnet

Terraform Configuration Files

resource "azurerm_virtual_network" "test" {
  name                = "test_vnet"
  location            = "westeurope"
  resource_group_name = "test-vnet-rg"
  address_space       = ["10.0.0.0/16"]

  tags = {
    environment = "Test"
  }
}

resource "azurerm_subnet" "test" {
  name                 = "test-subnet"
  resource_group_name  = "test-vnet-rg"
  virtual_network_name = azurerm_virtual_network.test.name
  address_prefixes     = ["10.0.1.0/24"]
}

# resource "azurerm_subnet" "test2" {
#   name                 = "test-subnet2"
#   resource_group_name  = "test-vnet-rg"
#   virtual_network_name = azurerm_virtual_network.test.name
#   address_prefixes     = ["10.0.2.0/24"]
# }

Debug Output/Panic Output

https://gist.github.com/csorzi/b73b0da76da8fa3a2294fd135922dc4d

Expected Behaviour

When deleting a subnet with azurerm_subnet resource and updating the resource azurerm_virtual_network the same time, the subnet deleted by azurerm_subnet should be deleted.

Actual Behaviour

When updating azurerm_subnet to delete some resource and updating azurerm_virtual_network (e.g.: tags) the same time, Terraform will first delete the subnet then do the updates to the vnet, but as the virtual network resource stores information about subnets it will redeploy the subnet deleted by azurerm_subnet.

Notes:

  • you can see the destruction and recreation of the subnet on Azure portal while terraform apply is running
  • this strange behavior can also be seen in virtual network's activity log
  • the redeployment of the deleted subnet won't persist in the state(as expected)

Steps to Reproduce

With the configuration example provided above:

  1. terraform apply
  2. Update VNET tag "environment" value to test2
  3. Delete/comment out azurerm_subnet.test resource
  4. Uncomment azuerrm_subnet.test2 resource
  5. terraform apply
  6. Check subnets on portal, test still remain

Important Factoids

No response

References

No response

csorzi avatar Apr 12 '22 09:04 csorzi

Note that the same thing happens with:

  • azurerm_route_table used with azurerm_route
  • azurerm_network_security_group used with azurerm_network_security_rule

Should I open separate issues for these?

csorzi avatar Apr 12 '22 09:04 csorzi

@csorzi no one issue is sufficient for this - digging into this this appears to be missing locks fwiw

tombuildsstuff avatar Apr 12 '22 09:04 tombuildsstuff

Hey @tombuildsstuff! Any updates on this?

csorzi avatar Apr 25 '22 16:04 csorzi

I read this situation a bit differently than @tombuildsstuff. But I'll certainly defer to the expert here.

A subnet references the name of a virtual network, not the ID of the virtual network. And as a result, Terraform doesn't recognize a dependency chain between the resources and incorrectly orders recreation operations. I actually think #13765 would resolve the issue specific to subnets.

There are other, similar scenarios of this behavior (e.g., storage accounts). In that instance, I drafted up a punch list based on my analysis to keep tabs on which resources were impacted and which are outstanding.

owenfarrell avatar May 01 '22 03:05 owenfarrell

Hi @csorzi ,

I managed to replicate the issue at my end & I opened #25057 to get this sorted.

@tombuildsstuff looking forward to have your feedback on this.

harshavmb avatar Feb 27 '24 17:02 harshavmb