Skip to content
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

Closed
bflad opened this issue Aug 25, 2023 · 1 comment · Fixed by #186
Closed

all: Updates for Protocol Version 5.4 and 6.4 #185

bflad opened this issue Aug 25, 2023 · 1 comment · Fixed by #186
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@bflad
Copy link
Contributor

bflad commented Aug 25, 2023

terraform-plugin-mux version

v0.11.2

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 the GetProviderSchema 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 the GetProviderSchema called so it knows which underlying provider server has each resource type. Injecting a GetProviderSchema 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 calling GetProviderSchema, ignoring any GetMetadata 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 the ServerCapabilities.GetProviderSchemaOptional flag. The GetMetadata RPC implementation can be setup similar to GetProviderSchema RPC, looping through each underlying provider server to make the RPC call and returning any errors. The GetProviderSchemaOptional server capability must not be announced at this phase, as each of the resource-specific RPCs will still be dependent on the routing information via GetProviderSchema.

To finish implementing the functionality:

  • The GetMetadata RPC should be wired to automatically fall back to the GetProviderSchema RPC without returning any GetMetadata associated errors. While not ideal, the GetProviderSchema information is guaranteed to work and contains the necessary resource type name information.
  • The resource-specific RPCs should be wired to populate the routing information, if not already populated, via GetMetadata/GetProviderSchema and the GetProviderSchemaOptional server capability should be enabled.
  • Updating the routing information should be protected via mutex to prevent multiple calls to the underlying provider servers.

It is anticipated that providers needing the memory usage improvements will upgrade these Go module dependencies at once:

  • terraform-plugin-go (targeting v0.19.0)
  • terraform-plugin-framework (targeting v1.4.0)
  • terraform-plugin-sdk (targeting v2.29.0)
  • terraform-plugin-mux (targeting v0.12.0)

References

@bflad bflad added the enhancement New feature or request label Aug 25, 2023
@bflad bflad added this to the v0.12.0 milestone Aug 25, 2023
@bflad bflad self-assigned this 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 bflad closed this as completed in #186 Sep 6, 2023
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
Copy link

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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant