Open fishfacemcgee opened 7 months ago
This may be related to #24662, which has #24664 opened to fix it.
@rcskosir #24664 only addresses the app_service_managed_certificate resource, which is not referenced in my example code. So unless there's some very weird data piping to make an unrelated resource relevant to azurerm_monitor_autoscale_setting
, I don't think it's related to #24662 besides being caused by the same change in 3.88.0 that was not fixed thoroughly enough in 3.89.0.
@fishfacemcgee The problem is that the service plane resource introduced a schema upgrade in v3.88.0, which changed the id format. As a result, resources dependent on the service plane id may experience drift issues. To resolve this, you should add an ignore_changes
meta argument as a workaround for the issue. I will submit a PR to normalize this type of case in the target_resource_id
field, but it may take some time for it to be released.
lifecycle {
ignore_changes = [target_resource_id]
}
@fishfacemcgee The problem is that the service plane resource introduced a schema upgrade in v3.88.0, which changed the id format. As a result, resources dependent on the service plane id may experience drift issues. To resolve this, you should add an
ignore_changes
meta argument as a workaround for the issue. I will submit a PR to normalize this type of case in thetarget_resource_id
field, but it may take some time for it to be released.lifecycle { ignore_changes = [target_resource_id] }
@wuxu92
Glad to hear a fix is being worked on, even if it's not super-soon. Will doing an apply with ignore_changes set up modify the state to reflect the new ID casing? If not, I think it makes more sense for the foreseeable future to stick with 3.87.0. Given how important that value is, I don't want to miss changes to it in the name of avoiding a provider bug.
@fishfacemcgee No, the ignore_changes won't modify the state file but ignore the changes in plan/apply just at its name's suggests.
Gotcha. Figured that was case but wasn't sure if that was just something internal to TF I wasn't aware of. Thanks for the clarification and thanks again for the future fix. 🙂
Is there an existing issue for this?
Community Note
Terraform Version
1.6.4
AzureRM Provider Version
3.89.0
Affected Resource(s)/Data Source(s)
azurerm_monitor_autoscale_setting
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Without a change to the resource implemented in the codebase, Terraform should not see the need to change any of the resources, let alone in a destructive manner.
Actual Behaviour
With a completely untouched repository minus upgrading to >= 3.87.0, Terraform wants to recreate the autoscaling group.
Steps to Reproduce
serverfarms
casingazurerm_monitor_autoscale_setting
that depends directly upon it as the target resource IDterraform init -upgrade && terraform plan
Important Factoids
No response
References
https://github.com/hashicorp/terraform-provider-azurerm/issues/24560 https://github.com/hashicorp/terraform-provider-azurerm/pull/24562