azurerm_log_analytics_workspace: on change of "sku", terraform incorrectly wants to rebuild workspace

[khaliddermoumi]

Community Note

• Please vote on this issue by adding a 👍 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 (and AzureRM Provider) Version

Terraform v0.13.7

• provider registry.terraform.io/hashicorp/azurerm v2.63.0

Affected Resource(s)

• azurerm_log_analytics_workspace

Terraform Configuration Files

resource azurerm_log_analytics_workspace log_analytics_workspace {
  name                = format("%s-%s-%s-%s", var.resource_name_prefix.log_analytics_workspace, var.project_name, "02", var.stage)
  location            = module.resource_group.location
  resource_group_name = module.resource_group.name
  # sku                 = "PerGB2018"
  sku = "CapacityReservation"
  reservation_capcity_in_gb_per_day = 100
  daily_quota_gb    = local.daily_quota_gb
  retention_in_days = var.retention_period
  tags = tags
}

Expected Behaviour

When changing the sku from "PerGB2018" to "CapacityReservation", the workspace should just have been updated, not destroyed. This change is easily doable in the portal or REST API without the workspace getting re-created.

Actual Behaviour

Terraform wants to delete the workspace due to the sku change:

  # azurerm_log_analytics_workspace.log_analytics_workspace must be replaced
-/+ resource "azurerm_log_analytics_workspace" "log_analytics_workspace" {
        daily_quota_gb             = 200
      ~ id                         = "/subscriptions/<edited>/resourceGroups/rg-monitoring-prd/providers/Microsoft.OperationalInsights/workspaces/<edited>" -> (known after apply)
        internet_ingestion_enabled = true
        internet_query_enabled     = true
        location                   = "westeurope"
        name                       = "<edited>"
      + portal_url                 = (known after apply)
      ~ primary_shared_key         = (sensitive value)
        resource_group_name        = "rg-monitoring-prd"
        retention_in_days          = 365
      ~ secondary_shared_key       = (sensitive value)
      ~ sku                        = "pergb2018" -> "CapacityReservation" # forces replacement
        tags                       = {
            "ProjectName"  = "monitoring"
        }
      ~ workspace_id               = "<edited>" -> (known after apply)
    }

Steps to Reproduce

1. change the sku, run terraform apply
2. terraform says it wants to replace the workspace

References

[riyadmurad]

reservation_capcity_in_gb_per_day is missing an "a" in compare to the documentation https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/log_analytics_workspace#sku

[joelw]

+1 to this - we just ran into this and it created all sorts of chaos.

I believe that it is possible to upgrade the commitment tier to a higher level at any time without deleting/recreating the workspace, so the azurerm provider should do this.

The commitment / SKU can only be downgraded during a certain time window. I think the azurerm provider should probably try to perform the downgrade and then emit a warning (or fail?) if it could not do so.

Deleting and recreating the workspace is something you almost never want to do, especially in production.

[JoshWeepie]

Just ran into this as well, will have to update it manually and then update the code it seems. The AZ CLI documentation doesn't show an explicit SKU change argument, but there is --set argument that can be used to set properties from az monitor log-analytics workspace show output.

https://learn.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-update

For example:

az monitor log-analytics workspace update --resource-group "rg" --workspace-name "name" --set properties.workspaceCapping.dailyQuotaGb=1

Or

az monitor log-analytics workspace update --resource-group "rg" --workspace-name "name" --set properties.sku.name=pergb2018

There is also the powershell cmdlet that could be used.

https://learn.microsoft.com/en-us/powershell/module/az.operationalinsights/set-azoperationalinsightsworkspace?view=azps-9.4.0

[JoshWeepie]

In case anyone else runs into this, if you are trying to change from a reserve tier to pay-as-you-go, and manually make a SKU change and then try to change your TF code to match -- for example from "CapacityReservation" to "pergb2018", the plan will actually say successful but the apply will still fail because it still has the 'reservation_capacity_in_gb_per_day' attribute as unchanged, even though 'reservation_capacity_in_gb_per_day' was removed from the code.

We had to state rm and import the workspace, then run TF plan and apply again in order to fix this issue.

[kudu-star]

What if for now simply update the SKU in portal and then TF should detect changes in code and import the change into code

[JoshWeepie]

@kudu-star See the comment above, that's what I did and we still ran into issues doing it that way without fixing tf state.

In case anyone else runs into this, if you are trying to change from a reserve tier to pay-as-you-go, and manually make a SKU change and then try to change your TF code to match -- for example from "CapacityReservation" to "pergb2018", the plan will actually say successful but the apply will still fail because it still has the 'reservation_capacity_in_gb_per_day' attribute as unchanged, even though 'reservation_capacity_in_gb_per_day' was removed from the code.
We had to state rm and import the workspace, then run TF plan and apply again in order to fix this issue.

[ziyeqf]

Hi all, thanks for opening this issue and the discussion.

This has been fixed by #22597 which will be released on v3.69.0, please note: downgrade the SKU is not allowed in 31 days after upgrade it. ( details )

For any further questions please leave comments.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.