`azurerm_monitor_autoscale_setting` attempting destructive drift due to Service Plan ID change

fishfacemcgee commented 7 months ago

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 and review the contribution guide to help.

Terraform Version

1.6.4

AzureRM Provider Version

3.89.0

Affected Resource(s)/Data Source(s)

azurerm_monitor_autoscale_setting

Terraform Configuration Files

# Note: This Resource was imported using Provider <= 3.87.0 so the ID in Terraform state
# has serverfarms in its path instead of serverFarms
resource "azurerm_service_plan" "file_service" {
  name = "FileServiceProdAppServicePlan"

  resource_group_name = var.resource_group-file_service-prod.name
  location            = var.resource_group-file_service-prod.location

  os_type  = "Windows"
  sku_name = "P1v2"

  tags = var.default_tags
}

resource "azurerm_monitor_autoscale_setting" "file_service-prod-autoscale" {
  name = "FileServiceProdAppServicePlan-Autoscale"

  resource_group_name = var.resource_group-file_service-prod.name
  location            = var.resource_group-file_service-prod.location
  target_resource_id  = azurerm_service_plan.file_service.id

  notification {
    email {
      custom_emails = [
        "test@example.com",
      ]
    }
  }

  profile {
    name = "Files - Scaling to 2 Servers during the weekdays."

    capacity {
      default = 1
      maximum = 1
      minimum = 1
    }

    recurrence {
      days = [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday",
      ]
      hours = [
        7,
      ]
      minutes = [
        0,
      ]
      timezone = "Eastern Standard Time"
    }
  }

  profile {
    name = jsonencode(
      {
        "name" = "Scale when we start to have too many connections"
        "for"  = "Files - Scaling to 2 Servers during the weekdays."
      }
    )

    capacity {
      default = 3
      maximum = 5
      minimum = 1
    }

    recurrence {
      days = [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday",
      ]
      hours = [
        22,
      ]
      minutes = [
        0,
      ]
      timezone = "Eastern Standard Time"
    }
  }

  tags = var.default_tags
}

Debug Output/Panic Output

N/A

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.

  # azurerm_monitor_autoscale_setting.file_service-prod-autoscale must be replaced
-/+ resource "azurerm_monitor_autoscale_setting" "file_service-prod-autoscale" {
      ~ id                  = "/subscriptions/-removed-/resourceGroups/FileServiceProdGroup/providers/Microsoft.Insights/autoScaleSettings/FileServiceProdAppServicePlan-Autoscale" -> (known after apply)
        name                = "FileServiceProdAppServicePlan-Autoscale"

      ~ target_resource_id  = "/subscriptions/-removed-/resourceGroups/FileServiceProdGroup/providers/Microsoft.Web/serverfarms/FileServiceProdAppServicePlan" -> "/subscriptions/-removed-/resourceGroups/FileServiceProdGroup/providers/Microsoft.Web/serverFarms/FileServiceProdAppServicePlan" # forces replacement
        # (3 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

Steps to Reproduce

Import a Service Plan using azurerm provider <= 3.87.0 in order for the resource to be in Terraform state with the old serverfarms casing
Create a azurerm_monitor_autoscale_setting that depends directly upon it as the target resource ID
Upgrade the provider to 3.89.0
terraform 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

rcskosir commented 7 months ago

This may be related to #24662, which has #24664 opened to fix it.

fishfacemcgee commented 7 months ago

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

wuxu92 commented 7 months ago

@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 commented 7 months ago

@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]
  }

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

wuxu92 commented 7 months ago

@fishfacemcgee No, the ignore_changes won't modify the state file but ignore the changes in plan/apply just at its name's suggests.

fishfacemcgee commented 7 months ago

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

hashicorp / terraform-provider-azurerm