Import of Container App Environment having problem with workload_profile

[elesandroo]

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.8.5

AzureRM Provider Version

3.108.0

Affected Resource(s)/Data Source(s)

azurerm_container_app_environment

Terraform Configuration Files

resource "azurerm_container_app_environment" "example" {
  name                               = "sey-cae01"
  location                           = azurerm_resource_group.example.location
  resource_group_name                = azurerm_resource_group.example.name
  infrastructure_resource_group_name = "${azurerm_resource_group.example.name}-dyn"
  infrastructure_subnet_id           = azurerm_subnet.subnet.id
  internal_load_balancer_enabled     = true
  zone_redundancy_enabled            = false
  workload_profile {
    name                  = "Consumption"
    workload_profile_type = "Consumption"
  }
}

import {
  to = azurerm_container_app_environment.example
  id = "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.App/managedEnvironments/sey-cae01"
}

Debug Output/Panic Output

# azurerm_container_app_environment.example must be replaced
  # (imported from "/subscriptions/xxx/resourceGroups/sey-cae-rg01/providers/Microsoft.App/managedEnvironments/sey-cae01")
  # Warning: this will destroy the imported resource
-/+ resource "azurerm_container_app_environment" "example" {
      
      + workload_profile { # forces replacement
          + name                  = "Consumption"
          + workload_profile_type = "Consumption"
        }
    }

Expected Behaviour

I would expect the terraform import to run without any changes. If you deploy this code instead of importing it, it completes successfully.

Actual Behaviour

Terraform plan tries to replace the resource because of workload_profile. If I remove it from the configuration, I get another error:

Error: Missing required argument
│ 
│   with azurerm_container_app_environment.example,
│   on main.tf line 39, in resource "azurerm_container_app_environment" "example":
│   39:   infrastructure_resource_group_name = "${azurerm_resource_group.example.name}-dyn"
│ 
│ "infrastructure_resource_group_name": all of `infrastructure_resource_group_name,workload_profile` must be specified

Steps to Reproduce

1. Deploy the code provided in the Terraform Configuration Files without the import command
2. Delete TF state files
3. Run terraform import of the Container App Environment

Important Factoids

No response

References

No response

[ned1313]

Issue confirmed with the supplied configuration. The produced plan in the before section has the following:

"workload_profile": [],

And this in the after section:

"workload_profile": [
                        {
                            "maximum_count": null,
                            "minimum_count": null,
                            "name": "Consumption",
                            "workload_profile_type": "Consumption"
                        }
                    ],

The issue appears to be specific to the Consumption profile type, which is a special profile type handled differently than other SKUs. To test, I used the following example configuration:

resource "azurerm_container_app_environment" "example" {
  name                               = "test-cae02"
  location                           = azurerm_resource_group.example.location
  resource_group_name                = azurerm_resource_group.example.name
  infrastructure_resource_group_name = "${azurerm_resource_group.example.name}-dyn2"
  infrastructure_subnet_id           = azurerm_subnet.subnet2.id
  internal_load_balancer_enabled     = true
  zone_redundancy_enabled            = false
  workload_profile {
    name                  = "D4"
    workload_profile_type = "D4"
    minimum_count = 1
    maximum_count = 2
  }
}

import {
  to = azurerm_container_app_environment.example
  id = "/subscriptions/{subID}/resourceGroups/example-cae/providers/Microsoft.App/managedEnvironments/test-cae02"
}

This returned a clean import plan with no changes to the Container App Environment.

[jiaweitao001]

Hi @elesandroo , thanks for opening the issue. The problem you are facing is caused by a special handing of Consumption profile. We are in a dilemma of how to handle this special profile type properly. May I ask what your scenario is and I can potentially provide a workaround? Thanks for your understanding.

[elesandroo]

Hi @jiaweitao001, we originally created this resource using the azapi_resource because azurerm_container_app_environment didn't support all of the parameters we needed. Now it does, so we want to import it into azurerm.

Our Container App Environment currently contains one Container App that should use the Consumption SKU.

Do you need some more information?

[ned1313]

To add a little more context to the issue, when a container app environment is created without an explicit Consumption SKU workload profile, Azure creates one implicitly. So this code:

resource "azurerm_container_app_environment" "example2" {
  name                               = "test-cae02"
  location                           = azurerm_resource_group.example.location
  resource_group_name                = azurerm_resource_group.example.name
  infrastructure_resource_group_name = "${azurerm_resource_group.example.name}-dyn2"
  infrastructure_subnet_id           = azurerm_subnet.subnet2.id
  internal_load_balancer_enabled     = true
  zone_redundancy_enabled            = false
  workload_profile {
    name                  = "D4"
    workload_profile_type = "D4"
    minimum_count = 1
    maximum_count = 2
  }
}

Would create a container app environment with two workload profiles, D4 and Consumption. However, in Terraform state there would only be the single D4 workload profile.

The current workaround is for the plugin to look and see if the Consumption workload profile is explicitly set in the configuration block. If it isn't, then the implicit Consumption workload profile returned by the Azure API is filtered out to prevent a diff with state.

The problem you're encountering is that during import, the resource Read function gets a stub state based on the resource type that doesn't include the actual configuration. The stub has an empty workload profile, so the Read function returns back a state that doesn't include the Consumption workload profile. That results in a diff between state and config and thus the planned change to create the Consumption workload profile that already exists.

Aside from changing how the resource itself is implemented, I don't see an easy workaround. You might as well leave it as an azapi_resource for now.

[elesandroo]

Thank you for the explanation. If I understand correctly, Consumption SKU will be created even if I don't configure any workload_profile?
If that is true, maybe you could change error handling of this problem?

Error: Missing required argument
│ 
│   with azurerm_container_app_environment.example,
│   on main.tf line 39, in resource "azurerm_container_app_environment" "example":
│   39:   infrastructure_resource_group_name = "${azurerm_resource_group.example.name}-dyn"
│ 
│ "infrastructure_resource_group_name": all of `infrastructure_resource_group_name,workload_profile` must be specified

infrastructure_resource_group_name can currently only exist when workload_profile is specified but there is no scenario where any workload_profile wouldn't exist, right?

So, if this error weren’t present, we wouldn’t have to configure workload_profile, which is forcing the replacement, and terraform import would work correctly (hopefully).

Of course, that’s only my thinking. I don’t know whether there are any other dependencies or complications.

[jiaweitao001]

Hi @elesandroo , you're right about Consumption profile, it will be created automatically even it's not configured.

Sorry for the miss leading error message here. The logic of this feature has changed quite a few times so it's not reflecting the most recent intentions. There will be a major release coming soon, that would fix the issue. Thanks for your understanding.

[elesandroo]

Okay, I will be checking the changelog and wait for some update then. Thank you for your assistance.
Should I close this issue?

[ned1313]

Hi @elesandroo , you're right about Consumption profile, it will be created automatically even it's not configured.

Sorry for the miss leading error message here. The logic of this feature has changed quite a few times so it's not reflecting the most recent intentions. There will be a major release coming soon, that would fix the issue. Thanks for your understanding.

@jiaweitao001 can you point me to the current WIP? I'm curious to see how it's being resolved. Thanks!

[jiaweitao001]

@ned1313 , there is a flag here in the provider for 4.0 features, the resolution is simply stop automatically adding this Consumption profile.

[jiaweitao001]

@elesandroo , I was not precise about Consumption profile's behavior in my last reply. The Consumption profile will be automatically attached only when there is another workload_profile configured.

[rcskosir]

Thanks for taking the time to open this issue. Have you been able to try this on any of the new 4.x versions to see if this issue still persists?

[elesandroo]

Hi @rcskosir, I was and nothing has changed.