-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
all: Updates for Protocol Version 5.4 and 6.4 #185
Comments
This was referenced Aug 25, 2023
bflad
added a commit
that referenced
this issue
Aug 25, 2023
bflad
added a commit
that referenced
this issue
Aug 29, 2023
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
bflad
added a commit
that referenced
this issue
Aug 29, 2023
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
bflad
added a commit
that referenced
this issue
Aug 29, 2023
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
bflad
added a commit
that referenced
this issue
Aug 29, 2023
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
bflad
added a commit
that referenced
this issue
Sep 6, 2023
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
jharley
added a commit
to honeycombio/terraform-provider-honeycombio
that referenced
this issue
Sep 8, 2023
) As explained in hashicorp/terraform-plugin-mux#185, a group of libraries need to be upgraded together (and dependabot is struggling to do that): * github.com/hashicorp/terraform-plugin-framework to v1.4.0 * github.com/hashicorp/terraform-plugin-go to v0.19.0 * github.com/hashicorp/terraform-plugin-mux to v0.12.0 * github.com/hashicorp/terraform-plugin-sdk/v2 to v2.29.0
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
Description
Terraform 1.6 is introducing new functionality which can greatly reduce memory utilization when there are multiple instances of same provider type, by only calling the
GetProviderSchema
RPC against one provider instance. This can be accomplished by the provider signaling to core that theGetProviderSchema
RPC is not required before other RPCs. While this is straightforward to accomplish within a provider with a single provider server implementation, e.g. a single SDK such as terraform-plugin-framework, with terraform-plugin-mux the situation is much more nuanced. Currently, the "routing information" in a mux server for resource-specific RPCs is based on having theGetProviderSchema
called so it knows which underlying provider server has each resource type. Injecting aGetProviderSchema
call to fill in the routing table when receiving another RPC would defeat the memory usage optimization.To cover this additional gap, the protocol is also being enhanced with a new
GetMetadata
RPC, which returns server capabilities and only a listing of each resource type name. A mux server can attempt this new lighter-weight RPC before callingGetProviderSchema
, ignoring anyGetMetadata
RPC unimplemented error as necessary.Proposal
For an initial functionality pass, each of the mux/translation server implementations will need to be updated to support the new
GetMetadata
RPC and the existence of theServerCapabilities.GetProviderSchemaOptional
flag. TheGetMetadata
RPC implementation can be setup similar toGetProviderSchema
RPC, looping through each underlying provider server to make the RPC call and returning any errors. TheGetProviderSchemaOptional
server capability must not be announced at this phase, as each of the resource-specific RPCs will still be dependent on the routing information viaGetProviderSchema
.To finish implementing the functionality:
GetMetadata
RPC should be wired to automatically fall back to theGetProviderSchema
RPC without returning anyGetMetadata
associated errors. While not ideal, theGetProviderSchema
information is guaranteed to work and contains the necessary resource type name information.GetMetadata
/GetProviderSchema
and theGetProviderSchemaOptional
server capability should be enabled.It is anticipated that providers needing the memory usage improvements will upgrade these Go module dependencies at once:
References
get_provider_schema_optional
server capability terraform#33486The text was updated successfully, but these errors were encountered: