Consider Surfacing Framework Type System Data for Config/Plan/State

[bflad]

Module version

v1.0.0

Use-cases

Provider developers should not need to drop down to the github.com/hashicorp/terraform-plugin-go/tftypes type system for advanced use cases that require working with schema-based data directly. In particular, tfsdk.Config, tfsdk.Plan, and tfsdk.State type Raw fields are currently tftypes.Value. Instead, providers should be able to work with the framework's type system for consistency, such as types.Object. If the tftypes data handling was still necessary by providers for whatever reason, they could still use the type implementations of ToTerraformValue() and FromTerraformValue() to roundtrip back and forth.

This effort would also help clean up a lot of framework internal logic that goes back and forth between the two type systems.

Proposal

This will require a large amount of design effort to complete successfully and this proposal is not currently exhaustive. It is being written in the context of closing out the generic #172.

Likely, some tftypes functionality such as walking and transforming values may be desirable in the framework type system or at least available internally within the framework.

Then, one of the following approaches could be taken to expose the data using the framework's type system:

Existing Type Approach

Add a new exported types.Object retrieval method to the existing tfsdk types. Deprecate the Raw field.

This introduces the least changes for providers and the framework, but does not fix the framework's technical debt imposed by the data storage being an exported tftypes.Value. Without a setter method, this also means that providers must use (types.Object).ToTerraformValue() to save the data back, which could be awkward.

New Type Approach

New schema-based data types could be introduced in the datasource, provider, and resource packages based off the framework type system which deprecate the existing tfsdk types. This enables fully executing the vision of each concept being self-contained within its own package in the framework. Various requests/responses would need the tfsdk based fields to be deprecated in preference of new fields using the new types.

This approach would also allow a more tailored design that no longer exposes any implementation details as errantly mutable fields, but more design would be needed on that front.

References

• Reexamine where we convert from Terraform values into attr.Values. #172
• Consider Refactoring tfsdk Config/Plan/State Logic into internal Package(s) #366

[bflad]

One additional note that I would like to cross-reference from #186 is that any potential new implementation of GetAttribute() and SetAttribute() should consider only accepting a single attribute name path step or a string that is wrapped as such. There are some difficulties and current inconsistencies with attempting to fetch data at deeper levels. Personally, I think it would be good to encourage the provider developer practice of working with the framework type system directly for nested data and creating new values, rather than trying to directly work with data based on deeper schema paths.