Provider compatibility after introducing WriteOnly attributes

Terraform Providers Plugin Development
1

I’ve seen that Terraform CLI is now able to express feature support (ephemeral, and soon write-only) to provider plugins. I’m assuming that this means a write-only attribute won’t necessarily break compatibility with previous releases of Terraform CLI (or OpenTofu).

But I’m curious about this example from the docs:

"password_wo": schema.StringAttribute{
  Required:  true,
  WriteOnly: true,
},

What’s the expected behavior when a resource containing such an attribute is run with an earlier release of Terraform CLI?

2

Making something Required + WriteOnly is essentially equivalent to only allowing practitioners managing said resource to use Terraform 1.11+. If the practitioner sets a write-only attribute that is required using a version of TF earlier than 1.11, they’ll get an error: terraform-plugin-framework/internal/fwserver/attribute_validation.go at e210315c7023d8cf105325d562b0abd164857a5c · hashicorp/terraform-plugin-framework · GitHub

If we know the client can’t satisfy the requirement of not storing this attribute to plan/state, then we can’t proceed further with the operation.

3

Thank you, @austin.valle.

I think practitioner here refers to the end user (devops person) who is writing .tf files. That’s how I’m using it below. Please correct me if I’m confused about that.

Would you please clarify this detail?

If the practitioner sets a write-only attribute that is required

Why “if” here? Required is a choice made by the provider developer, so the practitioner’s hand is forced, I think?

My understanding is that if the provider developer defines a schema with both Required and WriteOnly on a single attribute, then the developer will have broken compatibility with earlier releases of Terraform CLI.

Do I have that right?

Is the broken-ness limited to configuration’s which makes use of the offending resource?

I’m thinking of introducing a new resource with such a schema. If the only implication is that users who wish adopt the new resource must upgrade Terraform CLI, then I think it’s an acceptable compatibility trade-off.

4

I think practitioner here refers to the end user (devops person) who is writing .tf files.

Yep! We’re on the same page :+1:

Why “if” here? Required is a choice made by the provider developer, so the practitioner’s hand is forced, I think?

You’re correct, apologies, the “if” should have been “when” :laughing: . Yes, if you have an attribute with a WriteOnly + Required, you are forcing the end user to use Terraform 1.11+. The caveat is really just, that the end user is using the resource in their config at all.

Is the broken-ness limited to configuration’s which makes use of the offending resource?

Yes, so if the end user was not using the resource with the Required + WriteOnly, then they wouldn’t see the error message / wouldn’t be forced to upgrade. The error will appear when Terraform validates the configuration of said resource.

1 Like
5

Perfect.

Thank you for clarifying, @austin.valle

6

I think one thing to note here is that while the resource won’t break with older versions of Terraform, the write-only attribute will show up as a normal optional attribute, and should be documented as such. It’s not like the user could actually use it by mistake, since older versions of Terraform would error out if the provider treated it as write-only, but the error in that case would not be the most useful only indicating that the provider produced an invalid plan.

1 Like