Subnets on same vnet fail due to parrallel setup #3780
Comments
|
I'm getting this same error on Terraform 0.11.13 and AzureRM provider 1.33.1
This looks related to #3673 To overcome, we're setting explicit dependencies using "depends_on" but, that's an awful hack. |
|
UPDATE Configuration locals {
}
provider "azurerm" {
}
resource "azurerm_resource_group" "rg" {
name = "bug-3780-rg"
location = "eastus"
}
resource "azurerm_virtual_network" "vnet" {
name = "bug-3780-vnet"
location = "eastus"
resource_group_name = "bug-3780-rg"
address_space = ["192.168.14.0/24"]
}
resource "azurerm_subnet" "subnet1" {
name = "bug-3780-subnet1"
address_prefix = "192.168.14.0/28"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
}
resource "azurerm_subnet" "subnet2" {
name = "bug-3780-subnet2"
address_prefix = "192.168.14.16/28"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
}
resource "azurerm_subnet" "subnet3" {
name = "bug-3780-subnet3"
address_prefix = "192.168.14.32/28"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
}
resource "azurerm_subnet" "subnet4" {
name = "bug-3780-subnet4"
address_prefix = "192.168.14.48/28"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
}Output |
|
Same on |
|
#3673 has updated the code so that the subnet is locked instead of the vnet, but I think the vnet still needs to be locked as well |
|
@bcline760 and @florianrusch I'm curious whether the "dependent resource" referred to in the error is actually the vnet, or the resource group. Do you see the same error if you use a different resource group for each subnet? I'm not suggesting that as a fix, just as a test to narrow down which resource azure is still modifying behind the scenes. |
|
Looks like this error is happening in more places than just terraform. azure-powershell for example: Azure/azure-powershell#1817 . Adding the vnet lock back forces the subnets to create in serial (and running in serial is the workaround the powershell folks seem to be using for now), but might not carry over to modules running in parallel like the original issue reporter mentioned (note that the original report was for v1.31.0 which still had vnet locks in the subnet resource). Any way to treat these as retryable errors instead of aborting the run? In all cases I've seen so far, they have been temporary. |
|
I'm also seeing this issue regularly. I have multiple terraform state files for different module tests but they all share the same resource group and vnet. Interestingly, I'm using 1.33.1. Todays test log: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@tombuildsstuff no it does not. I've been experiencing this for a long time and always used the latest provider on ephemeral ci executors. Just wanted to confirm this issue in hope of getting a proper solution at some point. I'm running 10 module tests in parallel each night. They all have their own tfstate but they share the VNET as a data object. Then I see every morning that at least one of the tests has failed with this specific issue. The state of arts has been like this for at least 3 months. @Moeser I'm not sure if your change caused any new issues since 409 errors were seen both pre and post the change. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
For those running 1.33.1 and running into the
That would be great. I still feel like the Azure API should be adding retry headers when these 409s are retryable, but adding code to the resources would be a much quicker short term fix. |
|
馃憢 The recent locking changes have been rolled back in #4320 which has been merged into master -so that bug will ship in version Thanks! |
|
My setup is quite similar (and also got the same results with v1.33.0): I have a single virtual network with 4 subnets, and 4 security group also. I commented out all four group/subnet association - everything runs fine. If add back one security group association, and I run |
|
@Clausewitz45 I don't think that's related. And fyi you can fix that by adding lifecycle ignore changes security group id. |
|
@suonto thanks for mentioning it - it's a nice workaround for the issue (at least I can continue the provisioning of the infrastructure), but this should not be the default behavior. I thought it is related because I got the same error message, but it is working with just a single subnet - not with 3. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Anyone still having this?
|
|
I'm having following error with the
|
|
confirm happening when trying to create subnets in a loop with terraform 0.14 and azurerm version 2.41. |
|
Still having the problem with TF 0.14.7 and azurerm version 2.50... Need to have different subnets with serviceEndpoints and/or Delegations configured, which must be done in sequence as of ARM. Only solution ATM using |
|
Getting same problems with azurerm 2.65 Found a workaround to use |
|
This is still an issue happenning when associating subnets to route tables, or even when creating service endpoints. |
|
I have tried terraform apply --parallelism=1 and depends_on . But nothing seems to work for me. Has anyone found solution for this error? |
|
Similar error with latest terraform and provider version
During creation "azurerm_dns_a_record" in "for_each" loop receiving error that 409 Is any one know if it possible to limit deploy to specific for_each loop from asynchronous to synchronous? |
and others
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
Terraform Configuration Files
I'm not able to use the full configuration due to sensitive information in them. Please see this example:
Expected Behavior
The subnets and other configuration are created on the VNet.
Actual Behavior
Terraform seems to be attempting to apply the separate configurations to the VNet at the same time. I've tried adding dependencies between the subnets which solved the problem there, but it appeared again when attempting to use a azurerm_subnet_network_security_group_association resource:
Important Factoids
In our configuration, each subnet, security group combination is in its own module. We have explored using dependencies to ensure they run sequentially but this is not possible with the azurerm_subnet_network_security_group_association resource.
References
Possibly related to these?
The text was updated successfully, but these errors were encountered: