[DRAFT] Add support for write only attributes #1044

SBGoods · 2024-10-02T20:06:34Z

No description provided.

…r/metaschema` packages

…package

…oods/write-only-attributes # Conflicts: # go.mod # go.sum

…ResourceConfig` RPC

…rceState` RPC

…aSourceConfig`, `ValidateEphemeralResourceConfig`, and `ValidateProviderResourceConfig` RPCs

austinvalle

Great work @SBGoods! I left some comments but overall this is looking good, once the core support lands we can start verifying some of the edge cases

austinvalle · 2024-10-08T14:40:40Z

internal/fwschema/attribute.go

+
+	// IsWriteOnly should return true if the attribute configuration value is
+	// write-only. This is named differently than WriteOnly to prevent a
+	// conflict with the tfsdk.Attribute field name.


nit: should probably drop a note here that write-only is a managed-resource schema concept only 👍🏻

austinvalle · 2024-10-08T14:58:57Z

ephemeral/schema/bool_attribute.go

@@ -185,3 +186,8 @@ func (a BoolAttribute) IsRequired() bool {
 func (a BoolAttribute) IsSensitive() bool {
 	return a.Sensitive
 }
+
+// IsWriteOnly returns false as write-only attributes are not supported in ephemeral resource schemas.


nit: Could be helpful to reword this and potentially other/future docs (also relevant to provider/schema and provider/metaschema)

Rather than "not supported", I'd say specifically they are "not relevant" to ephemeral / provider schemas, as these schemas describe data that is explicitly not saved to any artifact.

austinvalle · 2024-10-08T15:53:45Z

ephemeral/schema/float64_attribute.go

@@ -188,3 +189,8 @@ func (a Float64Attribute) IsRequired() bool {
 func (a Float64Attribute) IsSensitive() bool {
 	return a.Sensitive
 }
+
+// IsWriteOnly returns false as write-only attributes are not supported in ephemeral resource schemas.


nit: not a big deal but I see some of the ephemeral attributes don't have new tests. In general it's probably not super important for these to have tests but since we already do that testing for providers/is_computed, probably fine to keep it 👍🏻

austinvalle · 2024-10-08T18:09:12Z

internal/fromproto5/applyresourcechange.go

@@ -43,6 +43,8 @@ func ApplyResourceChangeRequest(ctx context.Context, proto5 *tfprotov5.ApplyReso
 		Resource:       resource,
 	}

+	fw.ClientCapabilities = ApplyResourceChangeClientCapabilities(proto5.ClientCapabilities)


nit: This can just go in the struct literal above since there are no diagnostics to handle (similar note to any other client capabilities)

austinvalle · 2024-10-08T18:57:39Z

internal/toproto6/getproviderschema_test.go

+							"test_attribute": resourceschema.BoolAttribute{
+								Computed:  true,
+								WriteOnly: true,
+							},


nit: I know this won't hit the validation logic that would typically prevent this, just thought it was weird to have this in a test since it's not valid 😆

austinvalle · 2024-10-09T16:50:34Z

internal/fwserver/server_createresource.go

+				"Error modifying state",
+				"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),


Suggested change

"Error modifying state",

"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),

"Error Modifying State",

"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),

austinvalle · 2024-10-09T16:51:29Z

internal/fwserver/server_updateresource.go

+				"Error modifying state",
+				"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),


Suggested change

"Error modifying state",

"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),

"Error Modifying State",

"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),

austinvalle · 2024-10-09T16:54:21Z

internal/fwserver/write_only_nullification.go

+	"github.com/hashicorp/terraform-plugin-framework/types/basetypes"
+)
+
+func NullifyWriteOnlyAttributes(ctx context.Context, resourceSchema fwschema.Schema) func(*tftypes.AttributePath, tftypes.Value) (tftypes.Value, error) {


nit: maybe a comment here or above the calling of this function on why this exists. As this is something a provider developer technically could do on their own, but we're handling it for them. Terraform core will (or should eventually) throw a data consistency error if these values are non-null, so we're just ensuring that's the case.

austinvalle · 2024-10-09T16:58:12Z

internal/fwserver/write_only_nullification.go

+		}
+
+		// Value type from new state to create null with
+		newValueType := val.Type()


Should this type come from the schema/attribute instead?

austinvalle · 2024-10-09T17:02:11Z

internal/fwserver/write_only_nullification_test.go

Similar note to the other tests, for logic like this, would be nice to cover the full range of nested attributes/block combinations if reasonable.

Would also be nice to see tests related to custom types, like for example, it's possible to encounter tuple values with dynamic types, a custom type could return a collection with a dynamic element type, etc.

chrismarget-j · 2024-10-09T19:27:54Z

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 · 2024-10-15T14:30:56Z

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.

SBGoods added 16 commits September 23, 2024 15:59

Update terraform-plugin-go dependency

1871b38

Implement write only attributes in the resource/schema package

90cbd29

Implement write only attributes in the datasource/schema package

0f84c52

Implement write only attributes in the provider/schema and `provide…

2c9d3cb

…r/metaschema` packages

Implement write only attributes in the internal/testing/testschema …

1e41c4a

…package

Merge remote-tracking branch 'origin/av/ephemeral-resources' into SBG…

2279e84

…oods/write-only-attributes # Conflicts: # go.mod # go.sum

Update terraform-plugin-go dependency

a72206f

Implement write only attributes in the ephemeral/schema package

7328990

Populate writeOnly fields in internal/toproto5 and internal/toproto6

aacc3e8

Implement ValidateResourceConfigClientCapabilities in the `Validate…

ee78f76

…ResourceConfig` RPC

Add attribute validation for write only attributes

63adba2

Initial RequiredWriteOnlyNilsAttributePaths() implementation

32e1f49

Complete RequiredWriteOnlyNilsAttributePaths() implementation

9f83fe3

Implement validator.ValidateSchemaClientCapabilities

795ad64

Implement automatic write-only value nullification during `ApplyResou…

2d73905

…rceState` RPC

Explicitly set ValidateSchemaClientCapabilities during `ValidateDat…

23a025b

…aSourceConfig`, `ValidateEphemeralResourceConfig`, and `ValidateProviderResourceConfig` RPCs

austinvalle reviewed Oct 9, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DRAFT] Add support for write only attributes #1044

[DRAFT] Add support for write only attributes #1044

SBGoods commented Oct 2, 2024

austinvalle left a comment

austinvalle Oct 8, 2024

austinvalle Oct 8, 2024

austinvalle Oct 8, 2024

austinvalle Oct 8, 2024

austinvalle Oct 8, 2024

austinvalle Oct 9, 2024

austinvalle Oct 9, 2024

austinvalle Oct 9, 2024

austinvalle Oct 9, 2024

austinvalle Oct 9, 2024

chrismarget-j commented Oct 9, 2024

austinvalle commented Oct 15, 2024

		"Error modifying state",
		"There was an unexpected error modifying the NewState. This is always a problem with the provider. Please report the following to the provider developer:\n\n"+err.Error(),

[DRAFT] Add support for write only attributes #1044

Are you sure you want to change the base?

[DRAFT] Add support for write only attributes #1044

Conversation

SBGoods commented Oct 2, 2024

austinvalle left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrismarget-j commented Oct 9, 2024

austinvalle commented Oct 15, 2024