Case sensitivity issue with azurerm_kubernetes_cluster

[jwshive]

Is there an existing issue for this?

• I have searched the existing issues

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 Version

1.2.2

AzureRM Provider Version

3.8.0

Affected Resource(s)/Data Source(s)

azurerm_kubernetes_cluster

Terraform Configuration Files

resource "azurerm_kubernetes_cluster" "qa-test-automation-cluster" {
  location            = var.resource-location
  name                = "qa-pipeline-cluster"
  resource_group_name = azurerm_resource_group.resource-group.name
  tags                = merge(local.common-tags)

  azure_policy_enabled             = false
  enable_pod_security_policy       = false
  http_application_routing_enabled = false
  local_account_disabled           = false
  oidc_issuer_enabled              = false
  open_service_mesh_enabled        = false
  private_cluster_enabled          = false

  lifecycle {
    ignore_changes = [oms_agent]
  }

  identity {
    type = "SystemAssigned"
  }

  dns_prefix = "qa-pipeline-cluster-dns"

  default_node_pool {
    name                         = "agentpool"
    vm_size                      = "Standard_B2s"
    enable_auto_scaling          = true
    enable_host_encryption       = false
    enable_node_public_ip        = false
    fips_enabled                 = false
    kubelet_disk_type            = "OS"
    min_count                    = 3
    max_count                    = 10
    max_pods                     = 110
    node_labels                  = {}
    node_taints                  = []
    only_critical_addons_enabled = false
    orchestrator_version         = "1.22.6"
    os_disk_size_gb              = 128
    os_sku                       = "Ubuntu"
    tags                         = {}
    zones                        = ["1", "2", "3"]
  }

  network_profile {
    dns_service_ip     = "10.0.0.10"
    docker_bridge_cidr = "172.17.0.1/16"
    ip_versions        = []
    load_balancer_sku  = "standard"
    network_plugin     = "kubenet"
    outbound_type      = "loadBalancer"
    pod_cidr           = "10.244.0.0/16"
    service_cidr       = "10.0.0.0/16"
  }

  key_vault_secrets_provider {
    secret_rotation_enabled = false
  }

  oms_agent {
    log_analytics_workspace_id = azurerm_log_analytics_workspace.glubernetes-log-analytics.id
  }
}

Debug Output/Panic Output

# azurerm_kubernetes_cluster.qa-test-automation-cluster will be updated in-place
  ~ resource "azurerm_kubernetes_cluster" "qa-test-automation-cluster" {
        id                                  = "/subscriptions/my_subscription/resourcegroups/my_resource_group/providers/Microsoft.ContainerService/managedClusters/qa-pipeline-cluster"
        name                                = "qa-pipeline-cluster"
        tags                                = {
            "project-name"      = "gl"
            "resource-location" = "eastus"
        }
        # (23 unchanged attributes hidden)







      ~ oms_agent {
          ~ log_analytics_workspace_id = "/subscriptions/my_subscription/resourceGroups/my_resource_group/providers/Microsoft.OperationalInsights/workspaces/glubernetes-log-analytics" -> "/subscriptions/my_subscription/resourcegroups/my_resource_group/providers/microsoft.operationalinsights/workspaces/glubernetes-log-analytics"
            # (1 unchanged attribute hidden)
        }

        # (7 unchanged blocks hidden)
    }

Expected Behaviour

Resource isn't replaced

Actual Behaviour

Because of the case issues with "resourceGroup" vs "resourcegroup" the resource is constantly replaced. A lifecycle block mitigates this but should now be required.

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[jwshive]

This was initially built through the azure portal and then imported into terraform.

[nerddtvg]

For us, it appears the resource ID generated by the azurerm_log_analytics_workspace resource is all lower case.

resource "azurerm_kubernetes_cluster" "freight_science_kube" {
  ...

  oms_agent {
    log_analytics_workspace_id = azurerm_log_analytics_workspace.log_analytics_workspace.id
  }
  
  ...
}

resource "azurerm_log_analytics_workspace" "log_analytics_workspace" {
  name                = "workspace-name"
  ...
}

K8s Plan:
      ~ oms_agent {
          ~ log_analytics_workspace_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resourcegroupname/providers/Microsoft.OperationalInsights/workspaces/workspace-name" -> "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/resourcegroupname/providers/microsoft.operationalinsights/workspaces/workspace-name"
            # (1 unchanged attribute hidden)
        }

Linked resource:
$ terraform state show azurerm_log_analytics_workspace.log_analytics_workspace
# azurerm_log_analytics_workspace.log_analytics_workspace:
resource "azurerm_log_analytics_workspace" "log_analytics_workspace" {
    daily_quota_gb             = -1
    id                         = "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/resourcegroupname/providers/microsoft.operationalinsights/workspaces/workspace-name"
    ...
}

"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resourcegroupname/providers/Microsoft.OperationalInsights/workspaces/workspace-name"
"/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/resourcegroupname/providers/microsoft.operationalinsights/workspaces/workspace-name"

[nerddtvg]

After talking with @tombuildsstuff, he stated this is a formatter issue and will be resolved down the road when the log analytics resource is updated. However, a workaround is to state rm and import the workspace using the proper capitalization. This will be saved as the new ID and the AKS cluster will no longer have a bogus plan.

[stephybun]

Thanks for raising this issue @jwshive.

I believe this should have been resolved by #20484 which case insensitively parses the resource ID for the log analytics workspace. Upgrading to v3.44.0+ should fix this for you. I'm going to go ahead and close this for now. If you're still facing issues with the segment casing of the resource ID please let us know and we can reopen this!

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