Implement Protocol Version 5.3 and 6.3 (ServerCapabilities and PlanResourceChange on Destroy)
bflad opened this issue · comments
terraform-plugin-go version
v0.10.0
Use cases
Prior to Terraform 1.3, Terraform plans all destroy operations without consulting providers. New protocol functionality is now available for servers (providers) to announce support for capabilities, with destroy planning being the first capability. Providers can use this opportunity to return warnings or errors diagnostics when resource destruction is proposed, based on any business logic. This is opt-in to protect any existing implementations which may not be ready to receive an empty ProposedNewState
during the PlanResourceChange
RPC.
Attempted solutions
Without support in this Go module, one would have to directly interface with gRPC or fork this Go module with support.
Proposal
- Copy protocol buffer definitions for protocol versions 5.3 and 6.3
- Regenerate protocol buffer Go files
- Implement tfprotov5 and tfprotov6 types for
ServerCapabilities
, add toGetProviderSchemaResponse
, and wire conversions to/from protocol buffer Go types - Ensure tfprotov5/tf5server and tfprotov6/tf6server are all squared away with the new functionality
References
Terraform CLI v1.3.0-alpha20220706 is the first release with this support.
@bflad Thank you for introducing this new capability! I'm trying to understand when it should should be used.
Providers can use this opportunity to return warnings or errors diagnostics when resource destruction is proposed, based on any business logic.
Does this mean now the provider can left shift the error/warning at plan time, rather than fail at delete/apply time?
@magodo that is correct PlanResourceChange
handling code, the new capability has to be explicitly enabled by any providers written directly in terraform-plugin-go or the SDKs (terraform-plugin-sdk and terraform-plugin-framework) themselves for providers using those. terraform-plugin-framework 0.10.0 released with that capability enabled. terrafrom-plugin-sdk would require some thought before enabling it, since we cannot break compatibility with existing CustomizeDiff
logic that might not be ready for a wholly null plan value.