Resource azurerm_user_assigned_identity -> parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

[kevinharing]

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 v1.1.3 on windows_amd64

• provider registry.terraform.io/hashicorp/azuread v2.14.0
• provider registry.terraform.io/hashicorp/azurerm v2.91.0

Affected Resource(s)

• azurerm_user_assigned_identity

Terraform Configuration Files

resource "azurerm_user_assigned_identity" "xxx_uai" {
  name                = local.uai_name
  resource_group_name = data.azurerm_resource_group.uai_rg.name
  location            = data.azurerm_resource_group.uai_rg.location
}

Panic Output

Error: parsing "/subscriptions/xxx/resourcegroups/rg-xxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/xxx_uai": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

with azurerm_user_assigned_identity.xxx_uai,
on main.tf line 141, in resource "azurerm_user_assigned_identity" "xxx_uai":
141: resource "azurerm_user_assigned_identity" "xxx_uai" {

Expected Behaviour

Plan/Refresh succeeds

Actual Behaviour

Plan/Refresh fails with above error

Steps to Reproduce

1. terraform plan

Important Factoids

This still works on version 2.87.0, so a change must have happened in a higher version.

[robin-wayve]

This may be related to #14456.

[kevinharing]

@tombuildsstuff Why is this labeled as a question? This worked previously and it's keeping us from updating the provider version, because otherwise we can not deploy our software...

[lbergeron01]

This issue is also happening for us on azure_monitor_diagnostic_settings :

Error: parsing "/subscriptions/xxx/resourcegroups/rg-xxx/providers/microsoft.eventhub/namespaces/ehbns-xxx": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

with module.main.module.data_factory.module.key_vault.azurerm_monitor_diagnostic_setting.monitor_diagnostic_setting,
on ..\..\azure-terraform-modules\key-vault\key-vault\key-vault-main.tf line 114, in resource "azurerm_monitor_diagnostic_setting" "monitor_diagnostic_setting":
114: resource "azurerm_monitor_diagnostic_setting" "monitor_diagnostic_setting" {

---

CONFIG

In my file, I have 2 resources, one key vault and one databricks workspace which use the same eventhub for diagnostic settings.

TESTING

Debugging Logs

I've ran the plan command using TF_LOG=TRACE and I found the below information :

Databricks return the eventHubAuthorizationRuleId correctly : ``"eventHubAuthorizationRuleId":"/subscriptions/xxx/resourceGroups/RG-XXX/providers/Microsoft.EventHub/namespaces/EHBNS-XXX/authorizationRules/inc_xxx"

Key Vault return the eventHubAuthorizationRuleId in lower case : "eventHubAuthorizationRuleId":"/subscriptions/xxx/resourceGroups/rg-xxx/providers/microsoft.eventhub/namespaces/ehbns-xxx/authorizationrules/inc_xxx"

Postman test

I've tested using postman against the API URL :
https://management.azure.com/subscriptions/xxx/resourceGroups/RG-XXX/providers/Microsoft.KeyVault/vaults/KVXXX/providers/Microsoft.Insights/diagnosticSettings/setbypolicy_Diagnostics-Send-to-SIEM?api-version=2017-05-01-preview

And with available API version from Microsoft Documentation, and the result is always the same.

Manually create the diagnostic settings

I've dig further and found that all lower case resourcegroups come from a script we executed to enable diagnostics settings on all Key Vault. As a test, I've manually created a diagnostic settings config with the same parameters and then Terraform returned me a similar error message :

Error: parsing "/subscriptions/xxx/resourceGroups/RG-XXX/providers/Microsoft.EventHub/namespaces/EHBNS-XXX/authorizationrules/incoming_monitoringdata_policy": parsing segment "staticAuthorizationRules": expected the segment "authorizationrules" to be "authorizationRules"

CONCLUSION

I'm not familiar with the code behind the terraform provider, I'm wondering if :

1. Are these validation required?
2. If case is important, should a replace of resoucegroups to resourceGroups, and same for other value could be a solution?

Hope this clarify the issue.

LB

[gpltaylor]

I have the same issue where #14456 didn't fit the case issue.

Error: parsing Resource ID "/subscriptions/xxx/resourcegroups/production/providers/Microsoft.ManagedIdentity/userAssignedIdentities/aag-mi": parsing "/subscriptions/%subscription%/resourcegroups/%rg%/providers/Microsoft.ManagedIdentity/userAssignedIdentities/%resource%": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

When importing it looks like Case is being enforced and Azure is not the best at keeping this uniformed.

$terraform --version
Terraform v1.1.6
on windows_386
+ provider registry.terraform.io/hashicorp/azurerm v2.88.1

How I fixed (Do this at your own risk)
I don't recommend this as editing the stage file leads to madness, but in my case I needed to import an existing Identity

• Created a "new" Identity using TF
• Edit the State file and swap out the value with your existing Identity
• run TF apply -refresh-only

[murthyanish]

I'm getting this issue with azurerm_function_app resource under the key_vault_reference_identity_id parameter.
Provider version 2.99.0
I see that this was relabeled to Question, this is a legitimate bug and I'd like to request it be reopened.
This is related to #14456, but it did not get fixed with the solution to that.

Manually modifying the state file should not be the solution.

[torivara]

Experiencing the same with diagnostic settings and AzureRM 3.21.1, Terraform version 1.2.8. Seems to be related to updating from v2 to v3, but we didn't see this immediately. Took a few days for it to appear.

[ekarlso]

Any fix for this?

[torivara]

We just downgraded to 3.20.0 and everything worked again. Can't find anything in the changelog regarding this, but haven't tested 3.22.0 yet.

[Artlvns]

We just downgraded to 3.20.0 and everything worked again. Can't find anything in the changelog regarding this, but haven't tested 3.22.0 yet.

Tested and works for me as well on 3.20.0

[alex-goncharov]

same behavior with diagnostic settings on the storage account. Works on 3.20; broken on 3.22 and 3.23.

API returns resourcegroups

[cretzel]

same behavior with diagnostic settings on the storage account. Works on 3.20; broken on 3.22 and 3.23.

Deleting the diagnostic settings manually in azure and recreating them with terraform worked for me.

[abdourahaman]

I'm getting similar issue in servicebus context.
I'm using terraform version 1.2.9 and tested it with azurerm versions 3.20, 3.22, 3.23 and 3.24.

Error: parsing "/subscriptions/xxx/resourcegroups/rg-xxx/providers/Microsoft.ServiceBus/namespaces/sb-xxx/queues/queue-xxx/authorizationrules/xxx": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

with module.xyz.azurerm_servicebus_queue_authorization_rule.app,
resource "azurerm_servicebus_queue_authorization_rule" "app":

[AndreiShenets]

I'm getting similar issue in servicebus context. I'm using terraform version 1.2.9 and tested it with azurerm versions 3.20, 3.22, 3.23 and 3.24.

Error: parsing "/subscriptions/xxx/resourcegroups/rg-xxx/providers/Microsoft.ServiceBus/namespaces/sb-xxx/queues/queue-xxx/authorizationrules/xxx": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

with module.xyz.azurerm_servicebus_queue_authorization_rule.app, resource "azurerm_servicebus_queue_authorization_rule" "app":

The same happens for me.
I tried terraform version 1.3.2, 1.3.6, 1.3.7 and tested it with azurerm versions 3.37, 3.38

[containerpope]

We have a similar issue with an existing log analytics workspace after upgrading to azurerm 3.42.0.

╷
│ Error: parsing "/subscriptions/xxxx/resourcegroups/xxxx-xxxx-global-rg/providers/microsoft.operationalinsights/workspaces/xxxx-xxxx-prod-law": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"
│ 
│   with module.xxxx-xxxx-euw.azurerm_log_analytics_workspace.deploy_log_analytics,
│   on modules/xxxx-xxxx/main.tf line 33, in resource "azurerm_log_analytics_workspace" "deploy_log_analytics":
│   33: resource "azurerm_log_analytics_workspace" "deploy_log_analytics" {
│ 
╵

[jwshive]

Same thing is happening with azurerm_user_assigned_identity

parsing segment "resourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

Provider version hashicorp/azurerm v3.44.1

[rjhenry]

I'm getting the same attempting to import an AKS cluster:

Error: parsing Resource ID "/subscriptions/${REDACTED_SUBSCRIPTION_ID}/resourcegroups/${REDACTED_RESOURCE_GROUP}/providers/Microsoft.ContainerService/managedClusters/${REDACTED_CLUSTER_NAME}": parsing "/subscriptions/${REDACTED_SUBSCRIPTION_ID}/resourcegroups/${REDACTED_RESOURCE_GROUP}/providers/Microsoft.ContainerService/managedClusters/${REDACTED_CLUSTER_NAME}": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

Terraform v1.3.9 with provider v3.44.1 (and also with v.3.42.0).

EDIT TO ADD: I was able to work around this by changing the ID parameter of the terraform import call to have resourceGroups not resourcegroups in the ID:

@@ -1 +1 @@
-terraform import ${RESOURCE_ADDR} /subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.ContainerService/managedClusters/r${CLUSTER_NAME}
+terraform import ${RESOURCE_ADDR} /subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.ContainerService/managedClusters/r${CLUSTER_NAME}

Don't know if that'll be of any use to anyone else.

[tombuildsstuff]

@rjhenry

As per the error message being returned here, the Resource ID provided at import time doesn't match what's expected for the azurerm_kubernetes_cluster resource - we're expecting the format:

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1/providers/Microsoft.ContainerService/managedClusters/cluster1

however you're specifying:

/subscriptions/${REDACTED_SUBSCRIPTION_ID}/resourcegroups/${REDACTED_RESOURCE_GROUP}/providers/Microsoft.ContainerService/managedClusters/${REDACTED_CLUSTER_NAME}

Since the segment being provided (resourcegroups) doesn't match the segment we're expecting (resourceGroups), Terraform is highlighting this as an error:

expected the segment "resourcegroups" to be "resourceGroups"

As such you can fix this by updating the resourcegroups segment to be resourceGroups, which'll allow you to import this resource.

[tombuildsstuff]

👋

There's a few different issues at play here which all surface the same error message, but these are all related to the Resource ID format not matching what we're expecting, but these generally fall into:

1. Specifying a different Resource ID format/casing than is expected during terraform import - in this instance this can be worked around by checking the casing we're expecting for a given Resource ID, which can be found in the import section of the documentation for each resource - for example here's the import section for azurerm_kubernetes_cluster.
2. Updating from one version of the Provider to another raises an error along the lines of expected the segment "Foo" to be "foo". In this case the Resource ID may have previously been imported in a different casing, however Terraform should be accounting for this and auto-updating these IDs to account for it, meaning that this shouldn't show as a diff.
3. The Resource IDs are being defined by hand within the Terraform Configuration and use a different casing for the specified segment (for example resourcegroups rather than resourceGroups) than we're expecting/validating for.

In either case should the Resource ID casing differ from what we're expecting, then we'll highlight this issue when trying to parse the Resource ID - as in the error above expected the segment "resourcegroups" to be "resourceGroups" - means that we're expecting the segment resourcegroups within the Resource ID to be defined as resourceGroups rather than resourcegroups, which can be resolved by updating the casing of this segment.

Whilst we endeavour to provide State Migrations to automatically update the Resource ID casing where this changes - unfortunately if the Resource has previously been imported in a differing casing, there's not much we can do to workaround this unfortunately - and these'll need to be fixed by updating the Terraform Configuration / removing and re-importing this resource into your Statefile as needed.

As such if you're encountering this error message we'd encourage you to double-check the casing being specified matches the Resource ID format for the relevant Resource - but if you're still having an issue please feel free to open a new issue and we can clarify which it is.

However since the original issue here appears to be fixed (in #18467) and this has become a bit of a catch-all, I'm going to close this issue for the moment - but if you're still seeing this issue in the latest version of the Provider then please feel free to open a new issue and we can dig into what's going on here.

Thanks!

[AlexanderRijnbeek]

Sorry to reopen this but it is still happening :(

Error: parsing "/subscriptions/xxx/resourcegroups/xxx/providers/microsoft.operationalinsights/workspaces/xxx": parsing segment "staticResourceGroups": expected the segment "resourcegroups" to be "resourceGroups"

Terraform version 1.3.7
AzureRM Provider version 3.44.1

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