-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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_kusto_database_principal_assignment: Error: waiting for creation of Database Principal Assignment when using User Assigned Managed Identity #18355
Comments
Hi @jamesbwilkinson , I have tested locally with your config in version 3.22.0 and it works fine. Here is my config. provider "azurerm" { data "azurerm_client_config" "current" {} resource "azurerm_resource_group" "example" { resource "azurerm_user_assigned_identity" "user_identity" { resource "azurerm_kusto_cluster" "example" { resource "azurerm_kusto_database" "example" { hot_cache_period = "P7D" resource "azurerm_kusto_database_principal_assignment" "example" { tenant_id = data.azurerm_client_config.current.tenant_id Could you try with a higher version or check whether you assign this user_identity to kusto_cluster? If you still receving this error, welcome to leave a feedback here. |
I could confirm above config works in 3.7.0 as well :) |
Hi @liuwuliuyun Can you check it in this way? |
I am not sure how to use terraform in different stages, maybe other community members could give solid suggestions here. But I think you could update the cluster before assign the user_identity using azurerm_kusto_database_principal_assignment, that should work like above in theory. To make sure the assignment happens after the MI associated with cluster, you could try the depend on property of terraform |
To add to this: But anyhow: Could you try the approach without predefining the identities on the cluster, say, skip setting of "identity_ids" to check whether you can reproduce the issue? It worked on our side, but only after several trials. So maybe there is something that could be improved here. |
I tried following config on myside with version 3.7.0
After plan & apply and no error is promoted the first time. When I reapply after that, it promotes no change which is expected. |
If someone has the same issue and has a way to reproduce, welcome to leave a comments with steps :) |
Hi @liuwuliuyun, Thanks for your suggestion. I have tried to reproduce the issue using your example, and have done this in 2 ways:
My assumption here is that in attempt 1, the MI is created long before the ADX, as the ADX takes some minutes to become available. After this assignment is successful as the MI can be found. As in step 2 the time taken to create the MI and do the assignment appears not to be enough for the MI to be properly available in AAD. It appears that some delay/retry is needed between the MI creation and assignment for ADX. Could you test it from your-side as I did in attempt 2? |
We are also intermittently seeing this issue too, although interestingly only after upgrading from Terraform 1.1.7 to 1.3.4 but not sure if that is the cause. In our scenario we have an existing
We are currently on |
Hi @jamesbwilkinson I think your assumption is correct. In provider, we parrallel creating the resources except using depend_on to explicitly state the dependency. |
I tried your attempt and it succeed on myside. But I still think you are correct, could you try to make assignment depend_on the resource user_identity so that it will only be created after user_identity is created? For other resources having the same problem, similar approach could be tried.
|
Hi @liuwuliuyun , |
That is weird, I did not get any error like that. Here is the suggested config I menthoned.
After that I run As it can show that database assignments will be created only user_identity exists. Plus, you can remove the identity_ids block in kusto_cluster and it also works. My local terraform version is 1.2.3 but I dont think that is the problem. |
The dependency graph is correct but it seems that it kusto is not always able to immediately see an app registration after it is created and needs some amount of time before it works. It must be correct as in order to know the id of the app registration to use in the principal assignment it must have created it first. For now I am working around this by adding the database principal assignment outside of terraform but it's not ideal. Interestingly I found that doing it through Az PowerShell takes quite some time before it will error due to an incorrect id so I wonder if there is some kind of internal delay / wait to ensure new app registrations are detected. For us we are seeing that this issue is very much intermittent and we are not sure if the error message comes from the azure backplane or from something inside terraform. |
It appears to be an error from Azure API, a review of the Terraform logs shows the resource cannot be found: |
I am getting this error consistently when
We 'd like to avoid assignment creation outside of terraform, or some hacky wait with "external" data source using a CLI .. Any suggestions? versions installed:
Error msg (100% reproducible)
|
Is there an existing issue for this?
Community Note
Terraform Version
1.2.3
AzureRM Provider Version
3.7.0
Affected Resource(s)/Data Source(s)
azurerm_kusto_database_principal_assignment
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
I would expect the assignment to complete.
Actual Behaviour
The ADX assignment is not able to find the managed identity in the tenant. This seems to be a timing issue as the ID is available if manually searching AAD. After creation of the managed identity it must take some time for it to be available to ADX.
Steps to Reproduce
No response
Important Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: