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

fishfacemcgee commented 10 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 10 months ago

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

fishfacemcgee commented 10 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 10 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 10 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 10 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 10 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. 🙂

fishfacemcgee commented 1 week ago

@wuxu92 Apologies for the ping, but after running into the error discussed in #27466, I had tried updating my providers past 3.87 and it looks like this is still an issue, at least in 3.x of the provider. Do you know whether this was addressed in v4 by chance, or if this is still just an open issue?

hashicorp / terraform-provider-azurerm