-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azurerm_container_app_environment with infrastructure_subnet_id set is not idempotent #27481
Comments
Workaround is to set: lifecycle {
ignore_changes = [infrastructure_resource_group_name]
} Interestingly this "fixes" also all the other in-place updates shown above so that |
Hi @J0F3 , thanks for opening this issue. This is happening because originally if |
@jiaweitao001 Thanks, that would be great! However, I do not think it actually depends on if the consumption workload profile is defined or not, it actually depends on if a custom vnet (specified by If no custom vnet is used the infrastructure resource groups is completely hidden and maned by Azure itself. But when a custom vnet is used the infrastructure resource group is created in the customer subscriptions and the In general, I think the resource should not do anything with the |
Hi @J0F3 , the service will automatically generate a |
Yes I am aware of that and you are right that the resource group get created when So to be very sure we are on the same page I have created a test configuration with basically every combination. An here are the results: Consumption only environment without custom vnet:resource "azurerm_container_app_environment" "default" {
name = "default-acae"
resource_group_name = var.rg_name
location = var.location
} Result:
Ok, as expected Consumption only environment with custom vnet:resource "azurerm_container_app_environment" "default_vnet" {
name = "default-vnet-acae"
resource_group_name = var.rg_name
location = var.location
infrastructure_subnet_id = azurerm_subnet.default_vnet.id
} Result:
Ok, as expected. This is probably because, according the Azure documentation the Infrastructure Resource Group name can NOT be changed. Workload profiles environment using Consumption profile, without custom vnetresource "azurerm_container_app_environment" "workload_profile_consumption" {
name = "workload-profile-consumption-acae"
resource_group_name = var.rg_name
location = var.location
workload_profile {
name = "Consumption"
workload_profile_type = "Consumption"
}
} Result:
Ok, as expected. Workload profiles environment using Consumption profile, with custom vnetresource "azurerm_container_app_environment" "workload_profile_consumption_vnet" {
name = "workload-profile-consumption-vnet-acae"
resource_group_name = var.rg_name
location = var.location
infrastructure_subnet_id = azurerm_subnet.workload_profile_consumption_vnet.id
workload_profile {
name = "Consumption"
workload_profile_type = "Consumption"
}
} Result:
NOK, here is where the bug happens. Workload profiles environment using dedicated profile, without custom vnetresource "azurerm_container_app_environment" "workload_profile_dedicated" {
name = "workload-profile-dedicated-acae"
resource_group_name = var.rg_name
location = var.location
workload_profile {
name = "D4"
workload_profile_type = "D4"
maximum_count = 1
minimum_count = 1
}
} Result:
Ok. Workload profiles environment using dedicated profile, with custom vnetresource "azurerm_container_app_environment" "workload_profile_dedicated_vnet" {
name = "workload-profile-dedicated-vnet-acae"
resource_group_name = var.rg_name
location = var.location
infrastructure_subnet_id = azurerm_subnet.workload_profile_dedicated_vnet.id
workload_profile {
name = "D4"
workload_profile_type = "D4"
maximum_count = 1
minimum_count = 1
}
} Result:
NOK, here is where the bug happens, also. So as soon |
Btw. an other dependency is that |
Is there an existing issue for this?
Community Note
Terraform Version
1.9.5
AzureRM Provider Version
4.2.0
Affected Resource(s)/Data Source(s)
azurerm_container_app_environment
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Terraform apply should show no changes after initial apply. (Or at least it should update the
infrastructure_resource_group_name
in place as it is the case of other properties like static_ip_address, default_domain, etc.)Actual Behaviour
On every apply the Azure Container App Environment get recreated because of unexpected change of
infrastructure_resource_group_name
.Steps to Reproduce
terraform apply ( a second time)
Important Factoids
No response
References
While a custom resouce group can be specified it should also work with the default name (without specify any name) as it is the recommend way by Microsoft:
Otherwise, the provider should give an error when
infrastructure_resource_group_name
is specified butinfrastructure_resource_group_name
not.The text was updated successfully, but these errors were encountered: