Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support renaming resource types in addition to resource names #83

Closed
nnnkkk7 opened this issue Jan 26, 2025 · 5 comments · May be fixed by #88
Closed

Feature Request: Support renaming resource types in addition to resource names #83

nnnkkk7 opened this issue Jan 26, 2025 · 5 comments · May be fixed by #88
Labels
enhancement New feature or request

Comments

@nnnkkk7
Copy link

nnnkkk7 commented Jan 26, 2025

Feature Overview

Currently, tfmv can rename resource names (e.g., from example-1 to example_1), but it would be useful to also support renaming resource types (e.g., from aws_lambda_function to aws_serverless_function if such renaming occurs in provider updates).

Why is the feature needed?

When working with Terraform configurations, there are several scenarios where we need to rename resource types:

  1. Provider Updates: Sometimes providers deprecate and rename their resource types. For example, if a provider decides to rename aws_elasticsearch_domain to aws_opensearch_domain, we need to update all occurrences in our code.

  2. Provider Migration: When migrating between providers (e.g., from a community provider to an official one), resource types often need to be changed while keeping the same resource names and configurations.

Currently, this process is manual and error-prone, especially in large codebases. Having tfmv support resource type renaming would make these transitions much smoother and less error-prone.

Example Code

$  tfmv --type-replace "aws_elasticsearch/aws_opensearch"

Expected result:
before:

resource "aws_elasticsearch_domain" "example_1" {
  domain_name = "example-1"
}

data "aws_elasticsearch_domain" "example_2" {
  domain_name = aws_elasticsearch_domain.example_1.domain_name
}

after:

resource "aws_opensearch_domain" "example_1" {
  domain_name = "example-1"
}

data "aws_opensearch_domain" "example_2" {
  domain_name = aws_opensearch_domain.example_1.domain_name
}

moved {
  from = aws_elasticsearch_domain.example_1
  to   = aws_opensearch_domain.example_1
}

Note

@suzuki-shunsuke
Copy link
Owner

suzuki-shunsuke commented Jan 28, 2025

Terraform v1.8.0 introduced a mechanism like I was describing above to allow a provider to declare that it knows how to map resource instance data from one resource type to another.

If (and only if) the provider of the to resource type has logic to migrate the state data from the from resource type, Terraform Core will ask the provider to perform that translation and if successful will then proceed as if the object had been originally created as the new resource type.

https://github.com/hashicorp/terraform/blob/v1.8/CHANGELOG.md#180-april-10-2024

Providers can now transfer the ownership of a remote object between resources of different types, for situations where there are two different resource types that represent the same remote object type.
This extends the moved block behavior to support moving between two resources of different types only if the provider for the target resource type declares that it can convert from the source resource type.
Refer to provider documentation for details on which pairs of resource types are supported.

@suzuki-shunsuke
Copy link
Owner

I'm not sure if aws_opensearch_* has the logic to migrate the state data from aws_elasticsearch_*.
I've implemented the feature by #88 , but I don't have any resources to try it.

@nnnkkk7
Copy link
Author

nnnkkk7 commented Jan 28, 2025

@suzuki-shunsuke
Thanks for the detailed explanation and the implementation in #88 !
While the elasticsearch to opensearch example was used to illustrate the feature, I'll test it locally with my actual use case - the Snowflake resources migration based on https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md.

@nnnkkk7
Copy link
Author

nnnkkk7 commented Jan 28, 2025

@suzuki-shunsuke
I apologize for the confusion with my feature request. After testing locally, I received the following error which indicates this feature cannot be implemented as proposed:

Error: Move Resource State Not Supported
The "snowflake_account_role" resource type does not support moving resource
state across resource types.

I should have tested this before creating the issue. Thank you for implementing the feature (#88) and helping me understand the limitations with provider-level state migrations.
I'm sorry for wasting your time....🙇

@suzuki-shunsuke
Copy link
Owner

Oh, I see.
Don’t worry about it.
I close this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants