-
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
Remove Extraneous Caching of Resource Schemas #168
Comments
bflad
added a commit
that referenced
this issue
Jun 27, 2023
Reference: #168 This change removes the `GetProviderSchema` RPC-based caching logic in `NewMuxServer` and directly calls the underlying providers within that RPC. To fully support the removal of resource schema caching, the `PlanResourceChange` logic for checking the `ProposedNewState` data for a destroy plan was optimized to no longer require decoding the data with the type information. For larger scale providers (either number of resources and/or resources with large schemas), this should reduce resident memory utilization with little performance penalty.
bflad
added a commit
that referenced
this issue
Jun 28, 2023
Reference: #168 This change removes the `GetProviderSchema` RPC-based caching logic in `NewMuxServer` and directly calls the underlying providers within that RPC. To fully support the removal of resource schema caching, the `PlanResourceChange` logic for checking the `ProposedNewState` data for a destroy plan was optimized to no longer require decoding the data with the type information. For larger scale providers (either number of resources and/or resources with large schemas), this should reduce resident memory utilization with little performance penalty.
bflad
added a commit
that referenced
this issue
Jun 28, 2023
Reference: #168 This change removes the `GetProviderSchema` RPC-based caching logic in `NewMuxServer` and directly calls the underlying providers within that RPC. To fully support the removal of resource schema caching, the `PlanResourceChange` logic for checking the `ProposedNewState` data for a destroy plan was optimized to no longer require decoding the data with the type information. For larger scale providers (either number of resources and/or resources with large schemas), this should reduce resident memory utilization with little performance penalty.
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
Relevant provider source code
N/A
Terraform Configuration Files
N/A
Expected Behavior
terraform-plugin-mux should not cache resource schemas unless there is a really good reason as it inflates peak memory usage for providers. Currently all resource schemas are cached, which is problematic with larger providers (either in resource count and/or schema size). We are exploring whether Terraform itself can limit the amount of resource schema data being requested from providers to reduce overall memory utilization on both sides of the protocol. The resource schema caching in this Go module hinders any efforts in that regard though.
Actual Behavior
terraform-plugin-mux caches all resource schemas when creating a mux server. This caching is currently used with:
GetProviderSchema
RPC response based on all the underlying providers on mux server creation, which is itself because the mux server creation has historically implemented validation logic such as duplicate resource type detectionPlanResourceChange
RPC being sent to the underlying provider is a destroy plan, which is server capability based and the detection is based on fully decoding the ProposedNewState data using the actual schemaThe pre-loaded
GetProviderSchema
response is unnecessary and can likely be wholly deferred until after server startup and the actual RPC is called. The mux server already has a separate, small cache map for duplicate checking and raising implementation error diagnostics. There may be additional protocol changes necessary if the protocol implements "limited"GetProviderSchema
RPC requests though.For the
PlanResourceChange
cache usage:PlanResourceChange
JSON/msgpack data for nullity, rather than trying to fully unmarshal the data with the real schema.Steps to Reproduce
terraform validate
/terraform plan
/terraform apply
References
The text was updated successfully, but these errors were encountered: