tfsdk: Send UpgradeResourceStateResponse.UpgradedState.Msgpack for Terraform 0.12-0.14 Compatibility #262
Comments
|
Another option here would be to have |
|
Upon further consideration, this functionality should be implemented in this framework, rather than terraform-plugin-mux, whose implementations should be kept as straightforward routing or 1:1 translations. |
bflad
added a commit
that referenced
this issue
Feb 17, 2022
…pgradeResourceState RPC Reference: #42 Reference: #262 Reference: hashicorp/terraform-provider-corner#44 Terraform CLI version 0.12 through 0.14 support protocol version 5 and require the `UpgradeResourceStateResponse` type `UpgradedState` type `Msgpack` field. To support downgraded framework providers via terraform-plugin-mux `tf6to5server`, the `RawState` type `JSON` field cannot simply be passed through like the previous implementation. This change will parse the `RawState` and output it via the `tfprotov6.NewDynamicValue()` function, which will always set the `Msgpack` field. Similar logic would have already been required as part of the larger effort to support resource versioning and upgrading resource state over time. Passthrough of the same state of an invalid resource type should not have been previously allowed, since the provider did not implement the resource type. Regardless, Terraform CLI should not have reached this point since `GetProviderSchema` would not have returned the resource type anyways for other resource operations. Verified via integration testing of terraform-plugin-mux `tf6to5server`, which previously returned a non-descript `EOF` error.
bflad
added a commit
that referenced
this issue
Feb 22, 2022
…pgradeResourceState RPC (#263) Reference: #42 Reference: #262 Reference: hashicorp/terraform-provider-corner#44 Terraform CLI version 0.12 through 0.14 support protocol version 5 and require the `UpgradeResourceStateResponse` type `UpgradedState` type `Msgpack` field. To support downgraded framework providers via terraform-plugin-mux `tf6to5server`, the `RawState` type `JSON` field cannot simply be passed through like the previous implementation. This change will parse the `RawState` and output it via the `tfprotov6.NewDynamicValue()` function, which will always set the `Msgpack` field. Similar logic would have already been required as part of the larger effort to support resource versioning and upgrading resource state over time. Passthrough of the same state of an invalid resource type should not have been previously allowed, since the provider did not implement the resource type. Regardless, Terraform CLI should not have reached this point since `GetProviderSchema` would not have returned the resource type anyways for other resource operations. Verified via integration testing of terraform-plugin-mux `tf6to5server`, which previously returned a non-descript `EOF` error.
|
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.
Module version
Relevant provider source code
hashicorp/terraform-provider-corner#44
Expected Behavior
While the framework has not actually implemented
UpgradeResourceStatehandling (refer to #42), there is currently a passthrough implementation there since the RPC is always invoked. When passing a framework provider through terraform-plugin-muxtf6to5serverfor Terraform CLI 0.12+ compatibility, there should be no errors either.Actual Behavior
Terraform CLI 0.12 through 0.14 return the following (less than helpful) error:
This is because those versions of Terraform CLI requires the
Msgpackfield to be populated. This will require converting from RawState JSON and flatmap to MessagePack.Steps to Reproduce
Using any framework provider and
tf6to5server:terraform applyterraform applyUsing hashicorp/terraform-provider-corner#44:
go test ./internal/tf6to5providerReferences
terraform-plugin-framework/tfsdk/serve.go
Lines 493 to 497 in bf0240f
The text was updated successfully, but these errors were encountered: