Consider Automatic Handling of GetProviderSchema ServerCapabilities PlanDestroy #131
Comments
bflad
changed the title
bflad
added a commit
that referenced
this issue
Feb 2, 2023
…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
added a commit
that referenced
this issue
Feb 7, 2023
…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
added a commit
that referenced
this issue
Feb 8, 2023
…apabilities (#133) Reference: #131 This enables the mux servers to send the `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. 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.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
terraform-plugin-mux version
Use cases
Provider developers wishing to take advantage of resource destroy planning in Terraform 1.3+ with the framework currently cannot do so since the mux servers do not account for the new
ServerCapabiltiesdata fromGetProviderSchemaresponses. This support is enabled in framework servers automatically because it could afford the breaking change before it reached GA. This support is not being considered directly in sdk/v2 servers because it is a breaking change for existingCustomizeDiffcode, could potentially break SDK code, and regardless would require some sort of change in the mux code to enable it anyhow.Attempted solutions
Since the mux server code does wholly manages the
GetProviderSchemaresponse, there is no current mux server workaround except not muxing and only serving a framework server directly.Provider developers can leverage diagnostics during
ApplyResourceChangeby including the same logic inDeletefunctions/methods. This would be recommended for any provider which might need to support Terraform version prior to 1.3 anyways, since those practitioners would never see thePlanResourceChangediagnostics. One non-limitation is that plan logic can inspect configuration while apply logic cannot. This is not valid however, because apply logic in this case only has access to prior state, so it'd never be possible to use configuration values during apply.Proposal
In the mux servers, automatically drop (in a Terraform-valid way)
PlanResourceChangerequests if the mux server determined that the underlying provider server for the given resource type didn't ask to enable it from it'sGetProviderSchemaresponseServerCapabilities. The mux server would then likely need to always enable (or OR together) theServerCapabilities.Abandoned Ideas
ServerCapabilities-- this means that provider developers immediately would have to deal with any breaking changes toCustomizeDiffor the sdk/v2 code itself, etc. code just by trying to mux servers together.tfprotov5.ServerCapabilities/tfprotov6.ServerCapabilitiesobject during mux server creation. This will ensure that provider developers have exact control over what potential server capabilities are enabled across all their provider servers, although it does require additional discovery that will need to be called out in the framework documentation for the feature.References
The text was updated successfully, but these errors were encountered: