[ISSUE] databricks_permissions shows permanent drift if the owner is not the same as the TF identifier

[nkvuong]

Configuration

resource "databricks_permissions" "sql_warehouse" {
    access_control {
        group_name = "users"
        permission_level = "CAN_MONITOR"
    }
    sql_endpoint_id = "fba2ef8e11b2c0a3" # this endpoint is owned by a different principal
}

Expected Behavior

tf plan should be clean

Actual Behavior

tf plan shows planned changes

  ~ resource "databricks_permissions" "sql_warehouse" {
        id              = "/sql/warehouses/xxx"
        # (2 unchanged attributes hidden)

      - access_control {
          - permission_level       = "IS_OWNER" -> null
          - user_name              = "xxx.xxx@databricks.com" -> null
            # (2 unchanged attributes hidden)
        }
      - access_control {
          - group_name             = "users" -> null
          - permission_level       = "CAN_MONITOR" -> null
            # (2 unchanged attributes hidden)
        }
      + access_control {
          + group_name       = "users"
          + permission_level = "CAN_MONITOR"
        }
    }

Terraform and provider versions

1.48.2

Important Factoids

Running terraform apply does not clear the diff

[NiklasA]

I am encountering an simliar issue, where terraform apply shows changes every time it is run, even though no actual code/config modifications are being made.

Code:

variable "data_products" {
  description = "List of all data products with their respective attributes."
  type = list(object({
    id                = string
    repo_url          = string
    group_name_prefix = string
  }))
}

resource "databricks_permissions" "data_products_general_shared_autoscaling" {
  for_each = {
    for product in var.data_products : product.id => product
  }

  cluster_id = databricks_cluster.general_shared_autoscaling.id

  access_control {
    group_name       = "${each.value.group_name_prefix}_MANAGE"
    permission_level = "CAN_RESTART"
  }

  access_control {
    group_name       = "${each.value.group_name_prefix}_EDIT"
    permission_level = "CAN_RESTART"
  }

  access_control {
    group_name       = "${each.value.group_name_prefix}_RUN"
    permission_level = "CAN_RESTART"
  }

  access_control {
    group_name       = "${each.value.group_name_prefix}_MANAGE"
    permission_level = "CAN_ATTACH_TO"
  }

  access_control {
    group_name       = "${each.value.group_name_prefix}_EDIT"
    permission_level = "CAN_ATTACH_TO"
  }

  access_control {
    group_name       = "${each.value.group_name_prefix}_RUN"
    permission_level = "CAN_ATTACH_TO"
  }
}

Terminal

Plan: 0 to add, 5 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

[patrickwilliamconway]

I'm also seeing this state drift occur. I am working on migrating basic-auth --> oauth-m2m. All existing resources are owned by the root admin user, and I'm trying to now manage via a Service Principal.

[patrickwilliamconway]

hey @nkvuong, do you have any insight into fixing this? I tried going back a few versions but still was having this issue. The trouble is that I have existing resources that I can't easily destroy/recreate so I can't go back that far. I'm currently I'm just using a lifecycle to ignore the diffs. Not ideal, but 🤷

resource "databricks_permissions" "endpoint_usage" {
  sql_endpoint_id = databricks_sql_endpoint.endpoint.id

  access_control {
    group_name       = var.company_group_name
    permission_level = "CAN_USE"
  }

  lifecycle {
    # https://github.com/databricks/terraform-provider-databricks/issues/3730
    ignore_changes = [
      access_control
    ]
  }
}

Also, any chance underlying issue is related to #2543? I'm using databricks_permissions to manage a sql_warehouse, not a cluster, but I assuming they're somewhat related.

[alexott]

no, it's not related to #2543 - warehouses have their own permissions