Closed ethompsy closed 1 year ago
Looking at the debug output and comparing it to the Databricks API documentation I think the issue is the use of PUT
here. The API docs specify the use of POST
on creation of workspace assignment to a metastore:
https://docs.databricks.com/api/account/accountmetastoreassignments/create
I can recreate this using curl. If I try to create this same workspace assignment to the metastore using PUT
I get an HTTP 400 error like this:
< HTTP/2 400
< server: databricks
< date: Mon, 06 Nov 2023 20:06:34 GMT
< content-type: application/json; charset=utf-8
< content-length: 62
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-content-type-options: nosniff
< vary: Accept-Encoding
<
{ [62 bytes data]
100 62 100 62 0 0 116 0 --:--:-- --:--:-- --:--:-- 117
* Connection #0 to host accounts.cloud.databricks.com left intact
{
"error_code": "BAD_REQUEST",
"message": "Invalid UUID string: "
}
If I make the same call but change to a POST
request it is successful and returns an HTTP 200 response.
It seems that the provider is trying to migrate the metastore assignment from a now deleted workspace to the current workspace. I cannot imagine that this concept is compatible with the API?
Terraform will perform the following actions:
# module.data-hub-workspace.databricks_metastore_assignment.this will be updated in-place
~ resource "databricks_metastore_assignment" "this" {
id = "8410422733597792|80975123-190b-4c3b-9c8b-b659c9363e97"
~ workspace_id = 8410422733597792 -> 4568212316559807
# (1 unchanged attribute hidden)
}
In this case workspace with ID 8410422733597792
does not exist. The effect of this proposed change would be a call to the API using PUT
as shown in the debug log. However, the resource that is being updated does not yet exist.
In light of this I removed the the module.data-hub-workspace.databricks_metastore_assignment.this
object from the state and ran apply again. The assignment was created this time. It seems this issue might be caused by code changes that result in changes that rebuild the workspace. Such as I was going through during development.
There is a workaround for this. It is not ideal but it works. Since the databricks_metastore_assignment
is not really an independent object but a configuration of two independent objects, whenever this error comes up:
ā Error: cannot update metastore assignment: Workspace is not in the same region as metastore. Workspace region: Unknown, Metastore region: us-east-1
ā
ā with module.bi-workspace.databricks_metastore_assignment.this,
ā on .terraform/modules/bi-workspace/main.tf line 56, in resource "databricks_metastore_assignment" "this":
ā 56: resource "databricks_metastore_assignment" "this" {
ā
It is safe to just drop it from the state and run apply again.
$ terraform state rm module.bi-workspace.databricks_metastore_assignment.this
Not ideal, but it works for now.
@ethompsy we are merging a fix for this today and will try to include it in the next TF release today or Monday at the latest.
Hello! š
I am having some (apparently intermittent) issues attaching metastores to workspaces.
Configuration
Just following the guide here:
https://registry.terraform.io/providers/databricks/databricks/latest/docs/guides/unity-catalog#create-a-unity-catalog-metastore-and-link-it-to-workspaces
Expected Behavior
I would expect that the Databricks Terraform Provider would attach a metastore to a workspace that was just created.
Actual Behavior
Instead this error is thrown:
If I look in the Account UI I can see that the Workspace is known to be in
us-east-1
.Steps to Reproduce
terraform apply
Terraform and provider versions
Is it a regression?
I have tried
v1.29.0
,v1.28.1
,v1.28.0
,v1.27.0
, andv1.26.0
of the databricks provider. I am seeing the same issue in all of these so far.Debug Output
Important Factoids
We have been a Databricks customer for a long time and our accounts predate Unity Catalog and Account level SSO and many other features.