-
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_mssql_database_extended_auditing_policy and azurerm_monitor_diagnostic_setting cannot find master database at first run #22226
Comments
@ncseffai thanks for opening this issue. Could you double check the
|
The issue is still present with Terraform v1.5.3 & AzureRM provider v3.66.0. My resources are defined like so:
I get the ResourceNotFound for both
It works just fine when I run it second time. |
I am not sure I understand. If it didn't exists it would not run correctly for the second time, no? |
My guess is that it takes some time for master database to properly initialize after the SQL server is created (i.e. AzureRM API reports back to terraform that server is created before master is created). |
Yes, I agree. I believe this is causing the issue. What is also interesting that even if I set a timer that waits for 5 or 10 minutes and configure the terraform to wait for that before it runs azurerm_monitor_diagnostic_categories code snippet, it still fails! Should not terraform handle this internaly in its logic? |
I also tried it with a datasource to check for the existance of the master database, but that also fails the first time.
|
I hit this problem, but managed to solve it with a combination of
|
Interestingly this race condition hasn't been widely hit by me or others I work with (or just under reported) but I just had someone report it to me as well. My guess, without reading the code, is that the REST API isn't waiting for the Master Database to be created as it's a separate concern from provisioning the virtual resource and so the provider isn't waiting either. Is this something a custom poller could be created for in the create phase of the provider? Or is this against AzureRM Provider best practices? |
I don't know who this might help but i've just hit this issue and rather than adding waits/data blocks I set a |
Is there an existing issue for this?
Community Note
Terraform Version
1.5.0
AzureRM Provider Version
3.61.0
Affected Resource(s)/Data Source(s)
azurerm_monitor_diagnostic_setting / "azurerm_mssql_database"
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
After running the terraform apply, the SQL Audit should be enabled and configured to send the logs to the Log Analytics workspace, both on server level and on the DB01 database level.
SERVER LEVEL AUDIT SETTING
DB01 DATABASE LEVEL AUDIT SETTING
Actual Behaviour
On server level the audit is turned on, but the log analyitcs workspace is not configured as a destination. The reason for that is because at the first run there is an error stating the master database cannot be found. If the terraform plan / apply runs again, it will find the master database and the log analyitcs workspace will be configured correctly.
SERVER LEVEL AUDIT CONFIGURATION AFTER FIRST RUN
I tried to put timer to wait 5 minutes after the SQL server is created, but it does not solves the issue. However if I just rerun it again (plan/apply) it works immediately.
The terraform file based on this example (note this is for the older Terraform version, because the "log" is deprecated and "enabled_log" should be used.
https://github.com/hashicorp/terraform-provider-azurerm/blob/main/examples/sql-azure/sql_auditing_log_analytics/main.tf
For the DB01 database it configures it correctly after first run
Steps to Reproduce
terraform.exe plan -out=main.tfplan
terraform.exe apply main.tfplan
Important Factoids
No response
References
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/mssql_database_extended_auditing_policy
https://github.com/hashicorp/terraform-provider-azurerm/blob/main/examples/sql-azure/sql_auditing_log_analytics/main.tf
The text was updated successfully, but these errors were encountered: