[ISSUE][databricks_mws_workspaces] Adding private_access_settings_id forces replacement

[ktham]

We are attempting to enable AWS Privatelink on our existing Databricks workspaces, however, the terraform plan when adding private_access_settings_id to an existing Databricks Workspace forces a replacement.

Terraform Plan Output

-/+ resource "databricks_mws_workspaces" "main" {
      + cloud                      = (known after apply)
# ...
      ~ pricing_tier               = "ENTERPRISE" -> (known after apply)
      + private_access_settings_id = (known after apply) # forces replacement
# ...
    }

Expected Behavior

Should generate a plan with an in-place update

Actual Behavior

Generated a plan with that forces replacement of databricks_mws_workspaces resource

Steps to Reproduce

Create databricks_mws_workspaces without private_access_settings_id, and then add private_access_settings_id

Terraform and provider versions

TF version: 1.2.4 Databricks Provider version: 1.1.0

[alexott]

If you look into Account API docs, for part about updating workspace you will find following statement:

Note: You cannot use a network configuration update in this API to add support for PrivateLink (in Public Preview). To add PrivateLink to an existing workspace, contact your Databricks representative.

As described, you may try to enable it on the workspace via your Databricks representative, and then import new settings into Terraform state

[ktham]

@alexott Can you ensure that this is documented in the Terraform provider docs? This was not obvious at first and it seems like it will make it a bit complicated to handle on the Terraform side and it's unclear what the recommended route is. (e.g. add a lifecycle ignore rule? remove the resource from TF management and import it back in later? etc....) - Can you share what the recommended steps to take are?

[ktham]

In addition, I understand that there is an API limitation, but is forces replacement the correct behavior on the TF provider side? I would imagine not and this needs to be handled correctly?

[alexott]

If we don't force replacement, then state of the workspace won't match your desired state...

[ktham]

Thank you for following up @alexott!

If we don't force replacement, then state of the workspace won't match your desired state...

Ok, I'm assuming then that private_access_settings_id which then forces replacement, is the correct and intended behavior of the provider.

As described, you may try to enable it on the workspace via your Databricks representative, and then import new settings into Terraform state

Can you describe the "import new settings into Terraform state" part? This is the portion that we need help on and we are not clear how to proceed. Namely, some workspace resource does not support "import" according to your documentation:

• e.g. databricks_mws_workspaces -> https://github.com/databricks/terraform-provider-databricks/blob/f5e92fce1890077df27fbd13e26a471bbadaf543/docs/resources/mws_workspaces.md?plain=1#L240;L242

## Import

-> **Note** Importing this resource is not currently supported.

Or is what you mean by "import settings into Terraform state" the following: give the private_access_settings_id from the proposed Terraform plan that is causing the "forced replacement" of the databricks_mws_workspaces to our Databricks representative, and they will perform the update operation for us? And then once that's done, on the next Terraform plan, the resource gets refreshed with the private_access_settings_id value?

[alexott]

@ktham ah, sorry - I forgot that it couldn't be imported into terraform state :-( Not sure what would be the best way for fixing it then