all: Update to protocol version 5.4 and 6.4#186
Conversation
bflad
force-pushed
the
bflad/getproviderschema-optional
branch
3 times, most recently
from
1e941b2 to
2940589
Compare
Reference: #185 This implements protocol versions 5.4 and 6.4 in all provider server implementations, including enabling the `GetProviderSchemaOptional` server capability.
bflad
force-pushed
the
bflad/getproviderschema-optional
branch
from
2940589 to
29beaf7
Compare
bflad
changed the title
| resp := &tfprotov5.PrepareProviderConfigResponse{ | ||
| PreparedConfig: req.Config, // ignored by Terraform anyways | ||
| } |
There was a problem hiding this comment.
This might be the most awkward change to the mux server implementations in this change set -- previously PrepareProviderConfig/ValidateProviderConfig would check if each underlying provider returned an equal PreparedConfig response. This response field was for legacy Terraform usage (e.g. pre-0.12) where a provider could slightly change what core saw as the configuration data for a provider, such as injecting an environment variable value for a "required" provider configuration even though a value was not present in the real configuration. The only higher level provider SDK that enabled that behavior was terraform-plugin-sdk. This response field is ignored by any supported Terraform version that implements protocol versions 5 and 6 short of validating (at least currently) that it is either nil or that data value conforms to the provider schema. Therefore, while it may be safe to wholly omit the value (nil), we can instead use the framework's trick of just roundtripping the request configuration data which is guaranteed to be correct.
…data RPC and GetProviderSchemaOptional server capability (#311) Reference: #310 Protocol upgrades that impose new RPCs will either require: - The `tfprotov5.ProviderServer`/`tfprotov6.ProviderServer` interface to require a new method - Or, new "optional" interfaces be implemented (let's make up `ProviderServerWithGetMetadata` in this case) terraform-plugin-go is a low level abstraction which is designed to _directly implement_ the protocol rather than introduce its own abstractions. Most provider developers will directly interface with higher level Go modules, such as terraform-plugin-sdk and terraform-plugin-framework. Except for advanced provider development using this Go module directly, this type of low level "breaking" change will be hidden by also upgrading those Go modules at the same time: - hashicorp/terraform-plugin-sdk#1235 - hashicorp/terraform-plugin-framework#829 - hashicorp/terraform-plugin-mux#186 Therefore the change is implemented on the existing interface.
|
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. |
3 participants
Closes #185