A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.hashicorp.com/terraform/plugin/framework/migrating/workflow below:

Migration workflow | Terraform | HashiCorp Developer

For providers that only implement a few resources and other Terraform features, you can follow the workflow to migrate your provider in a single release cycle. For complex providers that support a number of resources and other Terraform features, we recommend that you follow the workflow to migrate over multiple release cycles to incrementally migrate your provider to the framework. Migration to the framework should not require any changes to configuration that uses your provider. Remember to only introduce breaking changes to your provider in major version updates.

This migration guide provides information and examples for most common use cases, but it does not discuss every nuance of migration. You can ask additional migration questions in the HashiCorp Discuss forum.

To learn more about the Terraform provider framework, refer to the framework documentation. To learn about the benefits of migration from SDKv2, refer to the migration guide.

Before you migrate your provider to the framework, ensure it meets the following requirements:

To reduce the risk of introducing breaking changes during migration, we strongly recommend that your ensure adequate test coverage before you begin migrating your provider to the framework.

To migrate your provider in a single release cycle, follow the steps below.

  1. Ensure the SDKv2 version of your provider has sufficient test coverage and that all tests pass.
  2. Review your provider code for SDKv2 resource data consistency errors, which might affect migrating to the framework. Some errors can be resolved and verified with SDKv2 code before you begin migration. Otherwise, you will need to resolve these errors as part of the migration.
  3. Serve your provider via the framework.
  4. Update the provider definition to use the framework.
  5. Update the provider schema to use the framework.
  6. Update each of the provider's resources, data sources, and other Terraform features to use the framework.
  7. Update related tests to use the framework, and ensure that the tests fail.
  8. Migrate the resource or data source.
  9. Verify that related tests now pass.
  10. Remove any remaining references to SDKv2 libraries.
  11. Verify that all of your tests continue to pass.
  12. Once you have completed the migration process and verified that your provider works as expected, release a new version of your provider.

To migrate your provider incrementally across multiple release cycles, you will use the terraform-plugin-mux module to implement a multiplex (mux) provider server.

Follow the steps below.

  1. Ensure the SDKv2 version of your provider has sufficient test coverage and that all tests pass.
  2. Review your provider code for SDKv2 resource data consistency errors, which might affect migrating to the framework. Some errors can be resolved and verified with SDKv2 code before you begin migration. Otherwise, you will need to resolve these errors as part of the migration.
  3. Serve your provider via the framework.
  4. Implement a mux server for your provider.
  5. Update the provider definition to use the framework.
  6. Update the provider schema to use the framework.
  7. Update each of the provider's resources, data sources, and other Terraform features to use the framework.
  8. Update related tests to use the framework, and ensure that the tests fail.
  9. Migrate the resource or data source.
  10. Verify that related tests now pass.
  11. During migration, follow your normal release process to fix bugs and add features to your provider. By relying on a mux server and test-driven development, the migration should not affect users of existing configuration.
  12. Remove the mux server configuration from your provider, as well as any remaining references to SDKv2 libraries.
  13. Verify that all of your tests continue to pass.
  14. Once you have completed the migration process and verified that your provider works as expected, release a new version of your provider.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4