Provide an upgrade path for SDKv2 providers #158
Comments
paddycarver
added
the
epic
|
We discussed the possibility of having a protocol 6 -> protocol 5 converter, similar to hashicorp/terraform-plugin-go-contrib#7 but in the opposite direction, that would allow provider developers to build providers with the framework that work on any version of Terraform after 0.12. To achieve this, we would need to disallow the use of nested attributes in that mode, likely as a panic or error in the conversion function if a nested attribute is returned as part of the schema. I'm not sure whether I think this is a good idea or not yet, but I'm recording it here for further consideration. |
Reference: #158 This enables provider developers to natively create and serve framework providers on protocol version 5, which is compatible with Terraform CLI 0.12 and later. For provider developers that are using terraform-plugin-mux to migrate from terraform-plugin-sdk to this framework, they can now omit the usage of the `tf6to5server` package by setting the `ServeOpts` type `ProtocolVersion` field to `5`. Any protocol layer restrictions with the older protocol version 5 are raised as errors from the framework. For example, if `Attributes` is defined in a `tfsdk.Attribute` ("nested attributes"), the `GetProviderSchema` RPC response will include an error diagnostic. This implementation is essentially a duplication of the `internal/fromproto6`, `internal/proto6server`, and `internal/toproto6` packages with renaming of 6 to 5 and any minor RPC naming differences to match the protocol (e.g. `ValidateDataResourceConfig` -> `ValidateDataSourceConfig`, `ValidateProviderConfig` -> `PrepareProviderConfig`, `ValidateResourceConfig` -> `ValidateResourceTypeConfig`).
Reference: #158 This enables provider developers to natively create and serve framework providers on protocol version 5, which is compatible with Terraform CLI 0.12 and later. For provider developers that are using terraform-plugin-mux to migrate from terraform-plugin-sdk to this framework, they can now omit the usage of the `tf6to5server` package by setting the `ServeOpts` type `ProtocolVersion` field to `5`. Any protocol layer restrictions with the older protocol version 5 are raised as errors from the framework. For example, if `Attributes` is defined in a `tfsdk.Attribute` ("nested attributes"), the `GetProviderSchema` RPC response will include an error diagnostic. This implementation is essentially a duplication of the `internal/fromproto6`, `internal/proto6server`, and `internal/toproto6` packages with renaming of 6 to 5 and any minor RPC naming differences to match the protocol (e.g. `ValidateDataResourceConfig` -> `ValidateDataSourceConfig`, `ValidateProviderConfig` -> `PrepareProviderConfig`, `ValidateResourceConfig` -> `ValidateResourceTypeConfig`).
|
The last item, creating a terraform-plugin-sdk migration guide, is started here: https://www.terraform.io/plugin/framework/migrating Closing! |
|
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. |
As we build out the framework and it becomes a viable replacement for SDKv2, we need to define the migration path for providers built on SDKv2 to be built on framework, instead. We don't want to make provider devs rewrite their entire provider in one fell swoop. Ideally, people would be able to migrate over one resource at a time. This is going to take some doing, so we can keep practitioner-facing breaking changes in the control of provider developers.
Figure out how to minimize impact of practitioners going from blocks to attributes #159even when providers can control it, it may be too much to ask of practitioners to insert(out of scope)=in so many places. If we ever want to get rid of blocks support, we need to solve this problem somehow.The text was updated successfully, but these errors were encountered: