Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

azurerm_application_gateway identity_ids are case-sensitive, and shouldn't be #10029

Closed
JohnDelisle opened this issue Dec 31, 2020 · 9 comments
Closed

Comments

@JohnDelisle
Copy link
Contributor

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

2020-12-31T22:01:19.0919305Z [command]C:\hostedtoolcache\windows\terraform\0.14.3\x64\terraform.exe version
2020-12-31T22:01:19.2411671Z Terraform v0.14.3
2020-12-31T22:01:19.2416643Z + provider registry.terraform.io/hashicorp/azurerm v2.41.0
2020-12-31T22:01:19.2417148Z + provider registry.terraform.io/hashicorp/random v3.0.0

Affected Resource(s)

  • azurerm_application_gateway

Terraform Configuration Files

NA - see output, it's an obvious issue

Debug Output

Observe the difference in case of "resourcegroups" vs. "resourceGroups" below in the identity_ids.

2020-12-31T22:01:36.2104268Z An execution plan has been generated and is shown below.
2020-12-31T22:01:36.2105043Z Resource actions are indicated with the following symbols:
2020-12-31T22:01:36.2105494Z   ~ update in-place
2020-12-31T22:01:36.2105690Z 
2020-12-31T22:01:36.2106027Z Terraform will perform the following actions:
2020-12-31T22:01:36.2106725Z 
2020-12-31T22:01:36.2396259Z   # module.main.module.app_role.module.appgw["centralus"].azurerm_application_gateway.appgw will be updated in-place
2020-12-31T22:01:36.2397258Z   ~ resource "azurerm_application_gateway" "appgw" {
2020-12-31T22:01:36.2398070Z         id                  = "/subscriptions/xxxx-xxxxx-xxxx-xxxx/resourceGroups/my-rg-name/providers/Microsoft.Network/applicationGateways/my-rg-name-app-appgw"
2020-12-31T22:01:36.2398843Z         name                = "my-rg-name-app-appgw"
2020-12-31T22:01:36.2399274Z         tags                = {}
2020-12-31T22:01:36.2399686Z         # (4 unchanged attributes hidden)
2020-12-31T22:01:36.2399979Z 
2020-12-31T22:01:36.2401223Z       ~ identity {
2020-12-31T22:01:36.2401805Z           ~ identity_ids = [
2020-12-31T22:01:36.2402571Z               - "/subscriptions/xxxx-xxxxx-xxxx-xxxx/resourcegroups/my-rg-name/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-rg-name-app-appgw-identity",
2020-12-31T22:01:36.2403722Z               + "/subscriptions/xxxx-xxxxx-xxxx-xxxx/resourceGroups/my-rg-name/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-rg-name-app-appgw-identity",
2020-12-31T22:01:36.2404459Z             ]
2020-12-31T22:01:36.2405439Z             # (1 unchanged attribute hidden)
2020-12-31T22:01:36.2406606Z         }
2020-12-31T22:01:36.2424697Z 
2020-12-31T22:01:36.2426449Z         # (21 unchanged blocks hidden)
2020-12-31T22:01:36.2426925Z     }

Panic Output

Expected Behaviour

The property is identical other than case, so resource does not need to be updated and should not be identified by terraform plan for an update.

Actual Behaviour

Terraform wants to update the resource

Steps to Reproduce

Important Factoids

This occurs every run, even after applying.. I run terraform apply again, and EVERY TIME it thinks it needs to update the App Gateway resource because the case differs. In case it's relevant, the identity ID is a property of a managed identity that's also created in the same Terraform, using a azurerm_user_assigned_identity resource type.

References

https://github.com/terraform-providers/terraform-provider-azurerm/blob/54c226cbac5fa28b6dfb08156114c71df33d04ae/azurerm/internal/services/network/application_gateway_resource.go#L87-L96

JohnDelisle added a commit to JohnDelisle/terraform-provider-azurerm that referenced this issue Dec 31, 2020
I believe this should address the issue of identity_ids being case-sensitive, resulting in terraform forcing an update on each apply due to case differences.  See issue hashicorp#10029
@dhmoto17
Copy link

dhmoto17 commented Jan 6, 2021

I'm seeing identical behaviour applying to a function app. The only difference is in the case of "resourceGroups" in the ID path.

I have tried providers 2.41.0, 2.30.0, 2.29.0, 2.20.0.

It is only happening for a function app that was created on 21st December, all my other function apps are fine (no changes in plan)

~ identity {
~ identity_ids = [
- "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/xx-xxx-identities-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/xx-xxx-fnapp-xxxxxxxxxx-xxxxxxxx-id",
+ "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/xx-xxx-identities-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/xx-xxx-fnapp-xxxxxxxxxx-xxxxxxxx-id",
]

Checking my terraform state it appears to be the output of resource azuread_identities_application that has changed behaviour, it is now outputting id with case "resourceGroups" rather than my previously created identities that are all lower case "resourcegroups"

@JohnDelisle
Copy link
Contributor Author

@dhmoto17 I'd suggest opening a new issue specific to that resource. Or, perhaps an over-arching issue asking for this to be fixed globally anywhere resource IDs are used.

@sharebear
Copy link
Contributor

We just tripped over this on function apps as well, @tombuildsstuff was doing a lot of work around this before the new year (might still be, I've not checked the git log recently), and he fixed a similar issue quickly for me... maybe he can weigh in on whether this should be separate issues or just one global for all places user assigned identities are used.

@sharebear
Copy link
Contributor

If I've understood the Id parsing framework correctly the fix is to make use of the UserAssignedIdentityId in flattenAppServiceIdentity (for function_app++) and flattenRmApplicationGatewayIdentity (for application_gatway).

@tombuildsstuff
Copy link
Member

Fixed via #10031

@sharebear looks like those are tracked in #10105 - so it's probably easiest just to track them there rather than a separate issue for now

@ghost
Copy link

ghost commented Jan 14, 2021

This has been released in version 2.43.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.43.0"
}
# ... other configuration ...

@ghost
Copy link

ghost commented Jan 18, 2021

I updated to version 2.43.0.

Now I have the following result in my terraform plan of the application gateway:

~ identity {
~ identity_ids = [
- "/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.ManagedIdentity/userAssignedIdentities/XXX",
+ "/subscriptions/XXX/resourcegroups/XXX/providers/Microsoft.ManagedIdentity/userAssignedIdentities/XXX",
]
}

I tries to switch from resourceGroups to resourcegroups on my application gateway.
Seems like this issue is not completely solved :-(

@tombuildsstuff
Copy link
Member

@danielweberoffice looks like we missed a state migration for this, apologies - but the fix for that is in #10196

@ghost
Copy link

ghost commented Feb 10, 2021

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Feb 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants