terraform-provider-azurerm
terraform-provider-azurerm copied to clipboard
azurerm_container_app_environment import not reading log_analytics_workspace_id from azure
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.3.8
AzureRM Provider Version
3.44.0
Affected Resource(s)/Data Source(s)
azurerm_container_app_environment
Terraform Configuration Files
resource "azurerm_container_app_environment" "environment" {
name = "containerappsenv-dev"
resource_group_name = "RG_DEV_fr"
location = "francecentral"
log_analytics_workspace_id = "/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.OperationalInsights/workspaces/workspacergdevfra2cf"
}
Debug Output/Panic Output
`terraform import azurerm_container_app_environment.environment subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev`
GET /subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev?api-version=2022-03-01 HTTP/1.1
Host: management.azure.com
User-Agent: Go/go1.19.3 (amd64-windows) go-autorest/v14.2.1 hashicorp/go-azure-sdk/managedenvironments/2022-03-01 HashiCorp Terraform/1.3.8 (+https://www.terraform.io) Terraform Plugin SDK/2.10.1 terraform-provider-azurerm/dev pid-222c6c49-1b0a-5959-a213-6608f9eb8820
...
2023-02-17T13:28:26.679Z [DEBUG] provider.terraform-provider-azurerm_v3.44.0_x5.exe: AzureRM Response for https://management.azure.com/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev?api-version=2022-03-01:
HTTP/2.0 200 OK
Api-Supported-Versions: 2022-01-01-preview, 2022-03-01, 2022-06-01-preview, 2022-10-01, 2022-11-01-preview, 2023-02-01
...
{"id":"/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev","name":"containerappsenv-dev","type":"Microsoft.App/managedEnvironments","location":"francecentral","systemData":{"createdBy":"<my-email-addrees>","createdByType":"User","createdAt":"2022-10-21T08:59:37.650008","lastModifiedBy":"<my-email-addrees>","lastModifiedByType":"User","lastModifiedAt":"2022-10-21T08:59:37.650008"},"properties":{"provisioningState":"Succeeded","defaultDomain":"calmglacier-86dd593e.francecentral.azurecontainerapps.io","staticIp":"20.74.15.245","appLogsConfiguration":{"destination":"log-analytics","logAnalyticsConfiguration":{"customerId":"9aca09af-89d1-4a86-82ad-be71f59fc219"}},"zoneRedundant":false}}: timestamp=2023-02-17T13:28:26.679Z
2023-02-17T13:28:26.681Z [WARN] Provider "registry.terraform.io/hashicorp/azurerm" produced an unexpected new value for azurerm_container_app_environment.environment during refresh.
- .name: was null, but now cty.StringVal("containerappsenv-dev")
- .platform_reserved_cidr: was null, but now cty.StringVal("")
- .static_ip_address: was null, but now cty.StringVal("20.74.15.245")
- .docker_bridge_cidr: was null, but now cty.StringVal("")
- .infrastructure_subnet_id: was null, but now cty.StringVal("")
- .internal_load_balancer_enabled: was null, but now cty.False
- .location: was null, but now cty.StringVal("francecentral")
- .log_analytics_workspace_id: was null, but now cty.StringVal("")
- .platform_reserved_dns_ip_address: was null, but now cty.StringVal("")
- .resource_group_name: was null, but now cty.StringVal("RG_DEV_fr")
- .tags: was null, but now cty.MapValEmpty(cty.String)
- .default_domain: was null, but now cty.StringVal("calmglacier-86dd593e.francecentral.azurecontainerapps.io")
Expected Behaviour
Imports all the configuration from the resource and terraform plan does not detect any changes on the resource.
Actual Behaviour
Following the successful import, when I run terraform plan it says it's going to recreate the resource because the log_analytics_workspace_id property has been set.
-/+ resource "azurerm_container_app_environment" "environment" {
~ default_domain = "calmglacier-86dd593e.francecentral.azurecontainerapps.io" -> (known after apply)
+ docker_bridge_cidr = (known after apply)
~ id = "subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev" -> (known after apply)
+ log_analytics_workspace_id = "/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.OperationalInsights/workspaces/workspacergdevfra2cf" # forces replacement
name = "containerappsenv-dev"
+ platform_reserved_cidr = (known after apply)
+ platform_reserved_dns_ip_address = (known after apply)
~ static_ip_address = "20.74.15.245" -> (known after apply)
- tags = {} -> null
# (3 unchanged attributes hidden)
- timeouts {}
}
Maybe it has to do with how the api exposes the log_analytics_workspace_id, since the az cli returns:
az containerapp env show -n containerappsenv-dev -g RG_DEV_fr
{
"id": "/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/providers/Microsoft.App/managedEnvironments/containerappsenv-dev",
"location": "francecentral",
"name": "containerappsenv-dev",
"properties": {
"appLogsConfiguration": {
"destination": "log-analytics",
"logAnalyticsConfiguration": {
"customerId": "9aca09af-89d1-4a86-82ad-be71f59fc219"
}
},
"customDomainConfiguration": {
"customDomainVerificationId": "CFC29A1271011CDF75FE215512A699D893091F2EAF3DE212CD510BDB536C5087"
},
"defaultDomain": "calmglacier-86dd593e.francecentral.azurecontainerapps.io",
"eventStreamEndpoint": "https://francecentral.azurecontainerapps.dev/subscriptions/<subscription>/resourceGroups/RG_DEV_fr/managedEnvironments/containerappsenv-dev/eventstream",
"provisioningState": "Succeeded",
"staticIp": "20.74.15.245",
"zoneRedundant": false
},
"resourceGroup": "RG_DEV_fr",
"sku": {
"name": "Consumption"
},
"systemData": {
"createdAt": "2022-10-21T08:59:37.650008",
"createdBy": "<my-email>",
"createdByType": "User",
"lastModifiedAt": "2022-10-21T08:59:37.650008",
"lastModifiedBy": "<my-email>",
"lastModifiedByType": "User"
},
"type": "Microsoft.App/managedEnvironments"
}
Is the go api returning the same info as the azure cli? Because it might be the transformation of the workspace id in the format of a resource id: "/subscriptions/subscription-id/resourceGroups/RG_DEV_fr/providers/Microsoft.OperationalInsights/workspaces/workspacergdevfra2cf" versus with the format returned by the api: "customerId": "9aca09af-89d1-4a86-82ad-be71f59fc219"
Steps to Reproduce
terraform import
terraform plan
Important Factoids
azure france central
References
No response
If I try and pass the workspace_id, that single guid, terraform plan responds with:
Error: parsing "9aca09af-89d1-4a86-82ad-be71f59fc219": expected 8 segments within the Resource ID but got 1 for "9aca09af-89d1-4a86-82ad-be71f59fc219"
Also just noticed, that after importing the existing container apps to terraform, adding tags in terraform and applying the only changes detected (the tags), it deleted my scale rules in all container apps and set the min replicas to null and max replicas to 10 (before it was 0-1).

I unfortunately ran into the same issue importing a container app environment using the last 3.52.0 azurerm provider. I was able to workaround it by going manually in the tfstate (hosted in an azure storage account) and edit the "log_analytics_workspace_id" line , which was set to "" and put the actual workspace Id used in Azure and present in my configuration.
I think I will hold off on using that approach as the container app resource still messed up my container apps as can be seen on the above screenshot. I've checked the realease notes for every release since then and I haven't seen a fix for these issues. Maybe it's an upstream dependency on the azure api? If I didn't have any other issues, I would use your fix ;D
Yeah there's definitely something going on with the apply on this resource or something. I did the same thing as @mendoncaftw, just added some tags and did a plan, plan showed just tag updates, so I applied. Come back to look at some system logs a week later and lo and behold, that apply to just add some tags also decided to remove my log analytics id from the resource so now I'm missing a weeks worth of logs. I didn't import my CAE though, mine was TF-ed cradle to grave so not sure how that would've happened but a definite problem for us going forward.
Also run into this issue.
I wrote some import blocks, but the terraform plan always wanted to recreate the azurerm_container_app_environment.
When I tried to copy the ID from azure portal into the tfstate like @itfranck wrote, I received this replacement:
# azurerm_container_app_environment.app_env must be replaced
-/+ resource "azurerm_container_app_environment" "app_env" {
~ default_domain = "adress.westeurope.azurecontainerapps.io" -> (known after apply)
+ docker_bridge_cidr = (known after apply)
~ id = "/subscriptions/uuid/resourceGroups/rgname/providers/Microsoft.App/managedEnvironments/env-name" -> (known after apply)
~ log_analytics_workspace_id = "/subscriptions/uuid/resourcegroups/rgname/providers/microsoft.operationalinsights/workspaces/analytics-name" -> "/subscriptions/uuid/resourceGroups/rgname/providers/Microsoft.OperationalInsights/workspaces/analytics-name" # forces replacement
name = "renv-name"
+ platform_reserved_cidr = (known after apply)
+ platform_reserved_dns_ip_address = (known after apply)
~ static_ip_address = "123.456.789.101" -> (known after apply)
- tags = {} -> null
# (3 unchanged attributes hidden)
- timeouts {}
}
Where the capitalization is wrong. Not sure against what azure provides this lowercase ID and thinks it's wrong because of that. When I fixed the capitalization in the tfstate it worked.
A workaround
lifecycle {
ignore_changes = [
log_analytics_workspace_id
]
}
We also encountered this issue, manually setting the id in the tf state file resolves it but it doesn't seem right to have to do that