[FEATURE] Add support for setting token expiration time in resource databricks_recipient

[andyLaurito92]

Use-case

We would like to setup via terraform a different token expiration time per recipient. We have several data assets that expose public data in which the expiration time could be set to unlimited thus avoiding the rotation process, while other data assets are private and do need an expiration time so we can have a better governance on them. Via the UI this is possible as it can be seen in the image below:

However, it doesn't seem possible via resource databricks_recipient

We would like the terraform provider to match the UI capabilities

Attempted Solutions

We tried the following solution

resource "databricks_recipient" "my_recipient" {
  name                = "my-recipient"
  comment             = "My super cool recipient"
  authentication_type = "TOKEN"
  tokens {
    expiration_time = 0
  }
  ip_access_list {
    allowed_ip_addresses = ["0.0.0.0/0"]
  }
}

and got the following error:

│ Can't configure a value for "tokens.0.expiration_time": its value will be
│ decided automatically based on the result of applying this configuration.

Proposal

I'm not quite sure about the solution, but is it possible that the issue is coming from this line, Concretely by setting tokens as SetReadOnly()?

[haho16]

@alexott , was there any reason to set TOKEN to readonly? In my view, it is not very useful to create the databricks_recipient if TOKEN expires and can't be re-generated using Terraform.

[alexott]

I think that it was before we introduced that token refresh functionality

[haho16]

So, there are 2 aspects here:

• being able to set expiration date explicitly
• refreshing token (recreate token block) once expired, similarly to workspace PAT token

Does it make sense to implement both for this resource?

[andyLaurito92]

Hi @haho16 @alexott

Is there any update on this feature? It would be nice to have it since it will allow us to deploy this via terraform instead via UI as we are currently doing.

@haho16 regarding your last comment: From a user perspective, it makes totally sense to me to allow both expiration date explicitly + token refreshens