databricks / terraform-provider-databricks

Databricks Terraform Provider
https://registry.terraform.io/providers/databricks/databricks/latest
Other
446 stars 385 forks source link

[ISSUE] Issue with `databricks_job` resource #2709

Open minico-dev opened 1 year ago

minico-dev commented 1 year ago

Configuration

dynamic "run_as" {
    for_each                  = each.value.workflow.git_source_url != null ? [1] : []
    content {
      user_name               = var.run_as_default_user
    }
  }

Expected Behavior

I created the Databricks Job by letting an Azure Service Principal apply the Terraform configuration. When I first created the resource I omitted the run_as block. Later I added it with the user_name set to a static user because of this product issue. I expect the job's run_as to be changed from the Service Principal that created the job to the user I specified.

Actual Behavior

During terraform plan and terraform apply, the change is prompted as I expected. I can see Terraform plans to change the value of run_as from the SP to the user. The terraform apply command states that modifications were successful, and the command finishes without errors. However, when checking the Databricks Workspace, the value is not changed at all, and still contains the SP. Also, upon inspecting the State file, the value is still set to the SP. When I completely remove the Job and recreate it using exactly the same specification (with the user_name set), the job's run_as parameter is correctly set to the user.

Steps to Reproduce

  1. terraform apply a databricks_job resource without the run_as block present in the specification, using a Service Principal
  2. After the job is created, edit the specification and set the run_as parameter to a specific user
  3. terraform apply, see that Terraform states that the modification was successful, while in fact is wasn't

Terraform and provider versions

Terraform 1.5.7 Databricks 1.26.0

smokedlinq commented 11 months ago

We are using the databricks bundle to deploy and seeing this same behavior. The state has the correct run_as value, but it is never set on the job itself.

smokedlinq commented 11 months ago

I did some testing and it doesn't look like the provider is wrong best I can tell, but the create api isn't respecting the passed values. I am able to use CLI to do a partial update on the job after the fact and it took the value as expected. I need to test creating a job with the api using CLI to see if it is the provider or API at fault.

databricks api post /api/2.1/jobs/update --json "{\"job_id\":\"12345657890\",\"new_settings\":{\"run_as\":{\"service_principal_name\":\"c14d4ea0-421c-4720-8794-c146747f8471\"}}}"
edwardofclt commented 10 months ago

Good morning, I discovered this morning that this is resolved (or at least worked around) by adding a databricks_permissions resource to assign the user as owner of the job.