[DRAFT] Add support for write only attributes

[SBGoods]

[chrismarget-j]

This will be super helpful. I'm looking forward to it being available.

When a plan is being generated, will the state value be used in place of a value picked up during Read()?

Put another, way, if a user amends the configuration of a write-only attribute, terraform will plan to call Update() for that resource?

Will Update() receive the previously configured value from resp.State.Get(), or will the state of that unreadable attribute be "unknown"?

[austinvalle]

Hey there @chrismarget-j 👋🏻, thanks for the interest and apologies there isn't a nicely written GH issue to discuss this feature on, this PR can suffice in the meantime 😆.

First some background: So the current idea for a write-only attribute is that the prior state will always be null, i.e. Terraform core will enforce that value is always written as null to state (there currently isn't any version of Terraform core that does this, so this PR isn't really testable ATM). With the prior state always being null, that means that the rule for deciding if a change (Update) is needed will be assigning any non-null value to the attribute.

Write-only attributes will be preceded by "ephemeral values" work in Terraform core, which allows describing variables as ephemeral, similar to how sensitive variables are described. (as well as providers being able to create a new ephemeral resource type, where all the attributes are considered ephemeral)

Write-only attributes will only be able to be populated by an ephemeral value, so the practitioner will need to model this new "intent", a very simplified example:

variable "new_db_password" {
  type      = string
  default   = null
  sensitive = true
  ephemeral = true
}

resource "aws_db_instance" "db" {
  # .. other attributes
  
  # This would be a new write-only attribute
  new_password = var.new_db_password
}

So with that background, to answer your questions:

When a plan is being generated, will the state value be used in place of a value picked up during Read()?

Put another, way, if a user amends the configuration of a write-only attribute, terraform will plan to call Update() for that resource?

Will Update() receive the previously configured value from resp.State.Get(), or will the state of that unreadable attribute be "unknown"?

So the state value will always be null, so there shouldn't be any prior state introduced for it during Read. I'm not sure how Terraform core plans to handle that data consistency ATM, but I'd expect an error if a provider attempted to refresh a state value into a write-only attribute.

That means that the provider will not be able to determine the previously configured value as it will always be null. Write-only attributes are essentially the provider describing that this attribute should not be managed by Terraform at all, so core is guaranteeing that the value is never stored to state.

If the user enters a new configuration value (or just sets up the configuration in a way where a value is just consistently provided), then a plan will be kicked off with that attribute's prior state as null and the config/proposed new value being the new config value. The provider still has the same plan modification opportunities, so you could, for example, propose a replace if the DB needed to be deleted/re-created when a new write-only attribute is provided.

[austinvalle]

@SBGoods Same as my SDKv2 PR comment, since we are already "managing" the setting of null for write-only attributes during plan/apply/read/etc. we need to ensure that we do this logic in every RPC where TF core is validating the null values in state (which is every RPC that has state as a response value). Currently I think this PR is missing the nulling logic on:

• ReadResource
• ImportResourceState
• UpgradeResourceState
• MoveResourceState