Open mariekekortsmit opened 10 months ago
Exactly the same problem in the first run for me but 2nd run does not fix it though. If I try it multiple times I then keep getting this error:
... Plan: 14 to add, 0 to change, 0 to destroy. │ Error: User not authorized │ │ with module.databricks.data.databricks_spark_version.latest_lts, │ on modules\databricks\main.tf line 9, in data "databricks_spark_version" "latest_lts": │ 9: data "databricks_spark_version" "latest_lts" { │
I'm really looking forward to trying out this solution because it seems to exactly what I was looking for. However, since I'm not familiar with Terraform I'm kind of stuck here.
@triplebeta, did you try waiting a bit before running it for the second time? It might be a race condition because we're deploying and authenticating to Databricks in the same terraform run.
Tried to run it 8 times, up to 20 minutes after the initial run. Same result each time.
I've installed terraform using the instructions from here, so it uses an SP with the Contributor role. Some resources (databricks, keyvault, sql, storage etc) show up properly in the resource group.
I enabled logging for terraform and this is what it shows:
`2023-11-28T13:58:17.201+0100 [WARN] Provider "registry.terraform.io/hashicorp/azurerm" produced an invalid plan for module.sql-database.azurerm_key_vault_secret.db_pw, but we are tolerating it because it is using the legacy plugin SDK. The following problems may be the cause of any confusing errors from downstream operations:
I hope that provides any clues for next steps. Is there anything else I should try?
@algattik any thoughts that you have that could potentially help @triplebeta out?
We should try splitting the deployment in two Terraform deployments (Azure resources, and Databricks resources) and see if that solves the problem. Any takers?
I want to give it a go, also an opportunity to learn some terraform. But before investing the time to split the files I'd like to know more sure that it wills solve the issue. I wonder which resources cause the problem and which account it is that fails to authorize. Understanding that might help find more solutions.
Assuming it's a race condition, could it help to add a sleep somewhere? Might be more convenient, secure and straight forward than having to split files, manage 2 states and pass variables.
UPDATE: Today I tried deploying the solution to a sandbox environment in our company and it worked flawlessly the very first run. Don't understand why but I can get started to test it and show it to colleagues. For me no more need to make changes.
If we choose to use this for real, we'll have to incorporate some parts into our own terraform scripts anyway to be compliant with the policies in our subscription.
Thanks for all you work setting up this sample, much appreciated!
This issue is for a: (mark with an
x
)Minimal steps to reproduce
Setting up the resources from scratch results in an error for the terraform apply in the first round:
Any log messages given by the failure
Expected/desired behavior
Desired behavior is not to have these failures in the first round, but have a successful deployment straight away. Running
terraform apply
once more results in a successful deployment after all, so consider adding this to a 'known issues' section.OS and Version?
WSL Ubuntu-20.04
Versions
Mention any other details that might be useful