azurerm_container_app_environment with infrastructure_subnet_id set is not idempotent

[J0F3]

Is there an existing issue for this?

• I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.9.5

AzureRM Provider Version

4.2.0

Affected Resource(s)/Data Source(s)

azurerm_container_app_environment

Terraform Configuration Files

resource "azurerm_container_app_environment" "aca_env" {
  name                = "someapp-acae"
  resource_group_name = azurerm_resource_group.aca_env.name
  location            = azurerm_resource_group.aca_env.location

  workload_profile {
    name                  = "Consumption"
    workload_profile_type = "Consumption"
  }

  infrastructure_subnet_id = azurerm_subnet.aca.id

  zone_redundancy_enabled = true
}

Debug Output/Panic Output

N/A

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.

  # azurerm_container_app_environment.aca_env must be replaced
-/+ resource "azurerm_container_app_environment" "aca_env" {
      ~ custom_domain_verification_id               = "[redacted] -> (known after apply)
      ~ default_domain                              = "somehting.switzerlandnorth.azurecontainerapps.io" -> (known after apply)
      + docker_bridge_cidr                          = (known after apply)
      ~ id                                          = "/subscriptions/[redacted]" -> (known after apply)
      - infrastructure_resource_group_name          = "ME_someapp-acae-cc50593250ca197-rg_switzerlandnorth" -> null # forces replacement
        name                                        = "someapp-acae"
      + platform_reserved_cidr                      = (known after apply)
      + platform_reserved_dns_ip_address            = (known after apply)
      ~ static_ip_address                           = "1.2.3.4" -> (known after apply)

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 but infrastructure_resource_group_name not.

[J0F3]

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 terraform plan shows 'no changes' after the initial apply as expected.

[jiaweitao001]

Hi @J0F3 , thanks for opening this issue. This is happening because originally if workload_profile is set to Consumption, infrastructure_resource_group_name will not be generated by the service. Seems this behavior has changed on the service side. We will fix this ASAP.

[J0F3]

@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 infrastructure_subnet_id) is used or not:
https://learn.microsoft.com/en-us/azure/container-apps/networking?tabs=workload-profiles-env%2Cazure-cli#managed-resources

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 infrastructure_resource_group_name gets set. But this happens independent of the workload_profile configuration.

In general, I think the resource should not do anything with the infrastructure_resource_group_name unless it is actually set by the user in the configuration.

[jiaweitao001]

@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 infrastructure_subnet_id) is used or not: https://learn.microsoft.com/en-us/azure/container-apps/networking?tabs=workload-profiles-env%2Cazure-cli#managed-resources

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 infrastructure_resource_group_name gets set. But this happens independent of the workload_profile configuration.

In general, I think the resource should not do anything with the infrastructure_resource_group_name unless it is actually set by the user in the configuration.

Hi @J0F3 , the service will automatically generate a infrastructure_resource_group_name if infrastructure_subnet_id and workload_profile are set, this behavior is out of TF's control. That is why we are seeing this diff here.

[J0F3]

Hi @jiaweitao001

the service will automatically generate a infrastructure_resource_group_name if infrastructure_subnet_id and workload_profile are set, this behavior is out of TF's control. That is why we are seeing this diff here.

Yes I am aware of that and you are right that the resource group get created when workload_profile and infrastructure_subnet_id is set.
But I does not matter if the Consumption workload profile is set or not. Do not confuse Workload profiles environments (where workload_profile is specified) with Consumption only environments (where workload_profile is not set.)! The Consumption workload profile is not the same as the as the Consumption only environments. Consumption only environments however can also have infrastructure_subnet_id but then the infrastructure_resource_group_name is not set by Azure an keeps null. I think that it is what you meant.

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:

"infrastructureResourceGroup": null

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:

"infrastructureResourceGroup": null

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 vnet

resource "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:

"infrastructureResourceGroup": null

Ok, as expected.

Workload profiles environment using Consumption profile, with custom vnet

resource "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:

"infrastructureResourceGroup": "ME_workload-profile-consumption-vnet-acae_..."

NOK, here is where the bug happens.

Workload profiles environment using dedicated profile, without custom vnet

resource "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:

"infrastructureResourceGroup": null

Ok.

Workload profiles environment using dedicated profile, with custom vnet

resource "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:

"infrastructureResourceGroup": "ME_workload-profile-dedicated-vnet-acae..."

NOK, here is where the bug happens, also.

So as soon infrastructure_subnet_id & workload_profile (regardless with which profiles) the bug happens.

[J0F3]

Btw. an other dependency is that infrastructure_subnet_id must be set to create a zone redundant container app environment with zone_redudancy_enabled=true.
Which also means that zone_redudancy_enabled=true can not be set unless also a subnet with infrastructure_subnet_id is provided. So maybe that is also something that the provider should check and enforce (if not already the case).
I saw now that this is already check by the provider. 👍🏻