azurerm version > 3.89.0 is breaking For/for_each loop parsing #24935
Comments
|
@BigFrog-coding you have duplicate role in the |
|
no I dont, the role key is created with the for loop. The issue is it is not reading the scope attribute in the object. In version 3.89.0 and previous versions it works fine |
|
@xuzhang3 Can you take another look please? I am surprised no one else is seeing this issue. |
|
@BigFrog-coding Can you check the roles in the local vals? Where is the roles from, the loop is build the role from it and it have duplicate values. |
|
The scope for every role is unique. The for loop creates the key based on scope and role_definition_id. I promise you there are not any duplicates, as it works just fine in version 3.89 and I have verified as well there are not any duplicates.
Have you even tried the code I gave you and the TF versions?
From: xuzhang3 ***@***.***>
Sent: Monday, March 4, 2024 10:59 PM
To: hashicorp/terraform-provider-azurerm ***@***.***>
Cc: BigFrog-coding ***@***.***>; Mention ***@***.***>
Subject: Re: [hashicorp/terraform-provider-azurerm] azurerm version > 3.89.0 is breaking For loop parsing (Issue #24935)
@BigFrog-coding<https://github.com/BigFrog-coding> Can you check the roles in the local vals? Where is the roles from, the loop is build the role from it and it have duplicate values.
You can reproduce this error by :
locals {
roles = {
roles1 = {
scope : "scope1"
role_definition_id : "def1"
principal_id : "principal_id1"
},
roles2 = {
scope : "scope1"
role_definition_id : "def1"
principal_id : "principal_id2"
}
}
}
-
Reply to this email directly, view it on GitHub<#24935 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AR7UBP7XQV56AHUPU6HUPA3YWU7HPAVCNFSM6AAAAABDQBTKAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHEZDINBZGE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@BigFrog-coding I ran the code, the error message is generated by Terraform and was thrown by the |
|
Yes, you are correct, but it is directly related to the Azurerm provider version, not Terraform itself. As it works in all versions prior to 3.89.
From: xuzhang3 ***@***.***>
Sent: Wednesday, March 6, 2024 1:09 AM
To: hashicorp/terraform-provider-azurerm ***@***.***>
Cc: BigFrog-coding ***@***.***>; Mention ***@***.***>
Subject: Re: [hashicorp/terraform-provider-azurerm] azurerm version > 3.89.0 is breaking For loop parsing (Issue #24935)
@BigFrog-coding<https://github.com/BigFrog-coding> I ran the code, the error message is generated by Terraform and was thrown by the for expression.
image.png (view on web)<https://github.com/hashicorp/terraform-provider-azurerm/assets/57888764/fb387a87-842c-4991-b33c-4af7d62abd98>
-
Reply to this email directly, view it on GitHub<#24935 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AR7UBP7N64JWYX5E22ZWM2DYW2XJTAVCNFSM6AAAAABDQBTKAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBQGE2TGNZUHA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
@BigFrog-coding the key issue here is the role has duplicated values, how do you get the roles? |
|
As stated, many times now, it is constructed/concatenated by the for loop using scope and role_id to create unique values. This works fine in 3.89 or lower, but broken with any 3.9 or higher azurerm provider version.
From: xuzhang3 ***@***.***>
Sent: Thursday, March 7, 2024 12:34 AM
To: hashicorp/terraform-provider-azurerm ***@***.***>
Cc: BigFrog-coding ***@***.***>; Mention ***@***.***>
Subject: Re: [hashicorp/terraform-provider-azurerm] azurerm version > 3.89.0 is breaking For loop parsing (Issue #24935)
@BigFrog-coding<https://github.com/BigFrog-coding> the key issue here is the role has duplicated values, how do you get the roles?
-
Reply to this email directly, view it on GitHub<#24935 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AR7UBPZU6WFEON27D7PV4V3YW734ZAVCNFSM6AAAAABDQBTKAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBSGQYDANRVHE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Greetings I have peer reviewed @BigFrog-coding results on my end. 3.99 Plan at 3.89 We are creating pim roles for Owner and Contributor We have a data call to gather subscriptions We filter in our locals: We create groups based on the local keys (2 resources, just showing the one) Then assign pim for these groups: with a lookup There is a clear discrepancy between the two versions using the same terraform Plan: 90 to add, 0 to change, 0 to destroy. |
|
Just a quick followup, |
|
@ABCodeMonkey that's a different issue to the one described above - see #24948 As @xuzhang3 has mentioned, the issue described above by @BigFrog-coding is a configuration issue, since there's duplicate keys in the map: Since the map keys are being built-up dynamically from an existing set of data, you'd need to check the source data that's being provided to find the duplicate - I'd suggest that Thanks! |
BigFrog-coding
changed the title
|
@tombuildsstuff Why did you close this issue? This is 100% not a configuration issue. Why would it work fine with Azurerm 3.89 and not work with any version greater than that? Please stop saying it is configuration issue when it clearly is not. I must insist you re-open this bug or I will recreate it until everyday until someone actually adresses the issue |
|
@BigFrog-coding both the error message in your original description: and the associated repro by @xuzhang3:
both show a configuration issue with the value being provided - that a duplicate key exists in the map (where Keys must be unique). Note that in the error message being output there's only a Role Definition shown, not a Scope - therefore the Scope must be an empty string (see `role.scope is "" in the error message) - which is likely the source of this conflict. As mentioned above, please double-check the source data being provided here, based on the error messages being returned - this isn't a bug in the Provider but an issue with the value being provided in the Configuration - and as such you'll need to check the source data being provided to diagnose this one. Whilst it's possible that there could be an issue with a Terraform Resource if that value is interpolated, unfortunately without validating the source data contains no duplicate values - which is what Terraform Core is highlighting is the source of the problem here - it's not possible to know which resource needs further investigation, but since Terraform Core is stating the problem is the source data, that's where I would start digging into this problem. |
|
@tombuildsstuff No it does not show a configuration issue, that is our point. You are seeing something that looks like configuration issue when in reality it is an issue with the Azurerm. The source data is a data call to pull all subscriptions and then the for loop creates dynamically a key for the loop based on the subscriptions. There is not any data that we are wrongly supplying. I assure you 100% there is not one duplicate value. I am happy to get into a call and talk it out if you like. Again, I request you re-open this bug or I will just keep submitting until I get some traction. |
|
Whilst I can understand you’re frustrated that this issue has been closed, please refrain from re-opening duplicates for this issue. Any duplicates will need to be closed in favour of this issue, and this work ultimately distracts maintainers from working on PRs and issues. As mentioned above: based on the Terraform Configuration provided in the issue description which returns the error “Two different items produced the key” - this is a configuration issue. Now - as you’ve alluded to in your last comment, there may well be another issue at play here - but the error message being returned here is only returned from Terraform Core when a map contains multiple keys with the same name, since a map must contain unique keys. In order for us to diagnose any separate issue, we’d need a reproducible Terraform Configuration (and ideally, debug logs) - so if you can provide that then we’re happy to take another look. However without that additional information we’re unable to ascertain if there’s another issue at play here, and we’re instead left with the error message being returned from Terraform Core: As such whilst I appreciate that you’re frustrated here, without a reproducible Terraform Configuration showing the issue coming from another Data Source/Resource - and/or without any debug logs, there isn’t much more we can do but look at the error message coming back from Terraform Core here. |
|
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. |
Is there an existing issue for this?
Community Note
Terraform Version
1.6.6
AzureRM Provider Version
3.92
Affected Resource(s)/Data Source(s)
azurerm_pim_eligible_role_assignment
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
The role key should have been created using the scope and role_definition_id in the for loop. TF plans
Actual Behaviour
│ Error: Duplicate object key
│
│ on pim.tf line 24, in resource "azurerm_pim_eligible_role_assignment" "pim_sub_eligible_assignment":
│ 23: for_each = toset({
│ 24: for role in local.roles : "${role.scope}${role.role_definition_id}" => role
│ 25: })
│ ├────────────────
│ │ role.role_definition_id is "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
│ │ role.scope is ""
│
│ Two different items produced the key "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c" in this 'for' expression. If duplicates are expected, use the ellipsis (...) after the value expression to enable grouping by key.
╵
scope is empty
This works great in all previous versions of azurerm provider
Steps to Reproduce
Terraform plan
Important Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: