tf5muxserver+tf6muxserver: Support GetProviderSchema response ServerCapabilities #133
Conversation
| @@ -112,6 +114,8 @@ func NewMuxServer(ctx context.Context, servers ...func() tfprotov5.ProviderServe | |||
| result.resources[resourceType] = server | |||
| result.resourceSchemas[resourceType] = schema | |||
| } | |||
|
|
|||
| result.resourceCapabilities[resourceType] = resp.ServerCapabilities | |||
There was a problem hiding this comment.
So from what i'm reading, this is where the provider developers enabling of PlanDestroy would occur. Do you have an example of what that would look like in a provider? I was looking through the AWS provider for example and couldn't get a good idea of where they would enable this.
Also, is PlanDestroy a framework-only feature or does it only matter what version of Terraform core they are using?
There was a problem hiding this comment.
I believe that calling PlanResourceChange RPC during destroy was introduced in Terraform core in v1.3.0 for providers that have "opted in":
provider plugin protocol: The Terraform CLI now calls PlanResourceChange for compatible providers when destroying resource instances.
PlanDestroy has been set to true in the Terraform Plugin Framework since v0.10.0:
tfsdk: The PlanResourceChange RPC on destroy is now enabled. To prevent unexpected Terraform errors, the framework attempts to catch errant provider logic in plan modifiers when destroying. Resource level plan modifiers may require updates to handle a completely null proposed new state (plan) and ensure it remains completely null on resource destruction.
I think that this means that if a provider developer is using Terraform Plugin Framework >= v0.10.0 with Terraform >= v1.3.0 then PlanResourceChange RPC will be called during destroy.
There was a problem hiding this comment.
Ah okay, so it's not necessarily something a provider developer opts-into directly then. Something they opt-into by usage of the framework.
Thanks for the breakdown! 👍🏻
There was a problem hiding this comment.
Created TF-613 to walk through the background here. Sorry for the confusion.
…apabilities Reference: #131 First, this enables the mux servers to capture and handle underlying `GetProviderSchema` RPC response `ServerCapabilities`. The first capability supported is `PlanDestroy`, which in Terraform 1.3+ will trigger Terraform to send the `PlanResourceChange` RPC to the provider during resource destroy. Any server capabilities enabled across the underlying servers use a logical OR to form the single mux server response. Enabling the RPC in that scenario unexpectedly for providers could cause either SDK or provider errors and panics. While the mux server will unilaterally enable the behavior for any resource type by nature of the single boolean field across the protocol, it will attempt to filter `PlanResourceChange` calls based on whether the underlying server signaled the capability. If determined to be a destroy plan and the server does not enable the capability, the mux server will send its own response without calling the underlying server.
bflad
force-pushed
the
bflad/server-capabilities
branch
from
5231dbb
to
21212aa
Compare
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #131
This enables the mux servers to send the
GetProviderSchemaRPC responseServerCapabilities. The first capability supported isPlanDestroy, which in Terraform 1.3+ will trigger Terraform to send thePlanResourceChangeRPC to the provider during resource destroy.Enabling the RPC in that scenario unexpectedly for providers could cause either SDK or provider errors and panics. While the mux server will unilaterally enable the behavior for any resource type by nature of the single boolean field across the protocol, it will attempt to filter
PlanResourceChangecalls based on whether the underlying server signaled the capability. If determined to be a destroy plan and the server does not enable the capability, the mux server will send its own response without calling the underlying server.