Open mendoncaftw opened 1 year ago
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
Is there an existing issue for this?
Community Note
Terraform Version
1.3.8
AzureRM Provider Version
3.44.0
Affected Resource(s)/Data Source(s)
azurerm_container_app_environment
Terraform Configuration Files
Debug Output/Panic Output
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.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
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