How to handle server side modified required attributes?

Terraform Providers Plugin Development
1

Hello,

I’m developing a provider and I have an attribute like this

"password": schema.StringAttribute{
		Required:  true,
		Sensitive: true,
},

In the terraform plan I define the plain text password like this

resource "myprovider_admin" "test" {
    username = "test"
    password = "plain text password"
}

The server receives the plain text password, generates and stores a hash and returns a blank password in the Read response.

The first error I had was:

Error: Provider produced inconsistent result after apply

I can avoid this error by copying the plan password to the state before saving the state like this:

state.Password = plan.Password // The returned password is blank, copy plain text password from the plan

// Set state to fully populated data
diags = resp.State.Set(ctx, state)
resp.Diagnostics.Append(diags...)
if resp.Diagnostics.HasError() {
	return
}

and I have to update the password from the state in both Read and Update methods.

Is this the correct way to handle use cases like this?

Should I instead store a blank password in state and tell Terraform to expect a blank password somehow?

I think I can have issues when importing existing resources, so if this is the correct way I have to disable the Import state.

Thanks in advance.

2

Hi @lists1 :wave: Thank you for raising this topic.

In general, Terraform has data consistency rules which require any configuration values to be saved into the state as-is, or it will generate errors as you found. Without that data in state, Terraform would have no methodology for performing difference detection should the value in the configuration change.

Is this the correct way to handle use cases like this?

That logic seems correct in this particular case. You will want to ensure you are not overwriting the prior (correct) value with a new (incorrect) value.

Should I instead store a blank password in state and tell Terraform to expect a blank password somehow?

If the blank password is attempting to be saved to the same attribute as the original one with the configuration value, Terraform should raise an error in this case. Refer to the data consistency rules above for more details.

I think I can have issues when importing existing resources, so if this is the correct way I have to disable the Import state.

Correct, if the API cannot return the actual value, then importing via only the API information cannot work without generating a difference on the first plan after import. You have a few options in this case, if you do want to still support import:

  • Allow import, but document an ignore_changes workaround.
  • Accept the real password value in the import ID, then when importing parse the import ID’s values into appropriate attributes. This is likely very undesirable.
  • Potentially see if future Terraform versions may provide a solution, which would enable this terraform-plugin-framework feature request (unfortunately I cannot publicly say more here).

Regardless of your choice there, it might be helpful to drop a :+1: on the framework feature request since having configuration information available during import might alleviate this particular issue.

Hope this helps.

1 Like
3

Thanks for the clarifications