Migrate to terraform plugin framework #365
Comments
|
If we can use muxing to do this gradually (i.e., only with one or two metal resources/data sources), then this could be a good way to start implementing new resources & data sources such that it's easier to run the tests for those new things in isolation. It would be good for us to understand the plugin framework before onboarding new service teams to terraform so that we can direct those service teams to build using the plugin framework from the start. |
Updating TF plugin sdk/v2 to latest in order to migrate to framework. Latest sdkv2 is one of the requirements for the migration. towards #365
|
I think we need to do #106 (internal/ refactoring) as a requirement of this work because per-resource packages are part of Framework's best-practices. If Framework can be introduced without moving the resources to separate directories//packages, this is not a concern. Example of the cyclic dependencies that we'll encounter if we don't move helpers first:
#142 implemented the internal/ refactor, but had problems getting E2E tests refactored to fit the pattern |
…asource for metal_ssh_key (#406) This PR is a first step towards migration from TF SDKv2 to the plugin Framework. It's along way, and Hashicorp documents it at [0]. We want to have both types of providers exist in the repo until we can totally migrate to framework. We need to use "muxing" [1]. I base this on the continuous migration of the Linode TF provider [2]. [3] is a first PR where they introduced the framework provider and migrated `token` resource to the framework format. For our case, I selected `metal_ssh_key` resource and datasource to migrate here, because those are simple resource types. [0] https://developer.hashicorp.com/terraform/plugin/framework/migrating [1] https://developer.hashicorp.com/terraform/plugin/framework/migrating/mux [2] https://github.com/linode/terraform-provider-linode [3] linode/terraform-provider-linode#791 Towards #365
…resource and datasource (#536) - Migration of `equinix_metal_gateway` and datasource `equinix_metal_gateway` - Definition of `WithTimeouts` (credits to https://github.com/hashicorp/terraform-provider-aws/blob/3d49b511a6e6f6c9ea8cddd4b4ac24b469985469/internal/framework/base.go#L148), intended to be embedded in resources which use the special "timeouts" nested block. It allows set default timeouts, in this case required for the Delete function. This change also allows users to change the default timeout: ```hcl resource "equinix_metal_gateway" "example" { ... timeouts { delete = "50m" } } ``` Resources that require defining default timeouts will need to configure them in its `NewResource` function using: **r.SetDefaultCreateTimeout(30 * time.Minute) r.SetDefaultReadTimeout(30 * time.Minute) r.SetDefaultUpdateTimeout(30 * time.Minute) r.SetDefaultDeleteTimeout(30 * time.Minute)** And extend Resource struct with `framework.WithTimeouts` ```go func NewResource() resource.Resource { r := Resource{ BaseResource: framework.NewBaseResource( framework.BaseResourceConfig{ Name: "equinix_metal_gateway", }, ), } r.SetDefaultDeleteTimeout(20 * time.Minute) return &r } type Resource struct { framework.BaseResource framework.WithTimeouts } ``` In order to keep the resourcheSchema function as standard as possible for all resources, I separated the timeouts block definition to the resource.go file where it will be required to override Schema func as below example: ```go func (r *Resource) Schema( ctx context.Context, req resource.SchemaRequest, resp *resource.SchemaResponse, ) { s := resourceSchema(ctx) if s.Blocks == nil { s.Blocks = make(map[string]schema.Block) } s.Blocks["timeouts"] = timeouts.Block(ctx, timeouts.Opts{ Delete: true, }) resp.Schema = s } ``` -- part of #365 --------- Signed-off-by: ocobleseqx <[email protected]> Co-authored-by: Tomas Karasek <[email protected]>
|
I have created an issue to track the migrated resources, can we close this one? |
|
As originally written, this issue has been completed: we've introduced muxing to support gradual migration of SDKv2 resources to the terraform-plugin-framework provider and have migrated a few resources to that provider. The process of migrating the remaining resources out of SDKv2 is captured in the issue Oscar linked above. |
Community Note
Description
Our Terraform provider is currently based on terraform-plugin-sdk which is no longer prioritized by Hashicorp and may not receive new features going forward.
The new hotness is the terraform plugin framework, which is getting the bulk of Hashicorp’s attention and has some useful things like built-in attribute validation so we can, for example, validate that strings are a certain length or match a regex without writing our own validation functions.
There is a migration guide here: https://developer.hashicorp.com/terraform/plugin/framework/migrating
Given the number of resources we have, we may want to use muxing (documented in the link above) to gradually convert the provider. Testing will be an issue because (1) Metal tests can be flaky and (2) Fabric and NE tests don’t exist (or at least, not in a way that we can run them ourselves on demand).
The text was updated successfully, but these errors were encountered: