Unable to move resource to new module #21346
Comments
|
It should be noted that current documentation for
|
|
We've had some success working around this with the following. Let's say we have an existing resource identified by # Import the component created by the old module into the new module.
# This create entries for the new module in the state.
terraform import module.new.resource_type.foo ABC123
# Delete the old module's state entry for that component.
terraform state rm module.old.resource_type.fooFrom here on out, the new module will exist in state and While this has worked for us, I want to make sure it is clear that this could potentially lead to state inconsistencies if not done correctly. Use this approach with caution. |
|
To be clear, @hwstovall's comment is not a method for moving modules and resources, but a full deletion of the old and import of the new. This is the obvious way to accomplish the end goal, but requires importing the resource(s) that are being "moved", which means you need to know something about the resource -- the format of the import string, and any details such as the resource name, ID, or other such property. This issue was created to highlight that the new version of the command line client was unable to move |
|
Also happens with final 0.12 versions. (I'm using 0.12.1.) Can't figure out a good way around this; @hwstovall's (incomplete) workaround is the best I can find. And I have to deal with "resource aws_cloudwatch_log_stream doesn't support import" |
sudoforge
changed the title
|
@pauldraper You could manually modify the state file, but this isn't recommended. If you have already migrated your plans to 0.12, however, that remains your only option for resources which do not support imports. |
|
Moving tf resource: Terraform version 0.12.1 |
|
@bohdanyurov-gl Thanks for reporting that you're experiencing the same issue! In the future, a simple 👍 reaction on the original comment is a great way to "me too" an issue. |
|
@sudoforge thanks for the tip; modifying the state file manually was indeed the solution I used. |
|
Alright, here is can move a resource to a new module in 0.12, with minimal risk: use a dummy resource (e.g. null_resource) in the new module, and Version 1 (initial)main.tf module "example" {
number = 1
source = "./example"
}example/main.tf variable "number" {}
resource "local_file" "file" {
count = var.number
content = "content"
filename = "${path.module}/file-${count.index}.txt"
}Version 2 (update, and failed mv)main.tf module "example" {
number = 0
source = "./example"
}
module "example2" {
number = 1
source = "./example"
}example/main.tf variable "number" {}
resource "local_file" "file" {
count = var.number
content = "content"
filename = "${path.module}/file-${count.index}.txt"
}Version 3 (create dummy, and successfully mv)main.tf module "example" {
number = 0
source = "./example"
}
module "example2" {
number = 1
source = "./example"
}example/main.tf variable "number" {}
resource "local_file" "file" {
count = var.number
content = "content"
filename = "${path.module}/file-${count.index}.txt"
}
resource "null_resource" "null" {}Version 4 (remove dummy)main.tf module "example" {
number = 0
source = "./example"
}
module "example2" {
number = 1
source = "./example"
}example/main.tf variable "number" {}
resource "local_file" "file" {
count = var.number
content = "content"
filename = "${path.module}/file-${count.index}.txt"
}(I did run into #21529 when I was trying this with more complex configurations, but I didn't record how I got around that.) |
|
Hi. Nice workaround with the dummy in the module, although it's impractical when you're getting the module from git or something like that. So here is a way to do the exact same thing without modifying your module source, hacking the statefile instead. Of course the usual warning apply, that could eat your statefile: terraform state pull |jq --arg module_path module.dali --arg null_id $(uuidgen) '.resources+=[{module:$module_path,mode:"managed",type:"null_resource",name:"dummy",provider:"provider.null",instances:[{schema_version:0,attributes:{id:$null_id,triggers:null},private:"bnVsbA=="}]}]|.serial+=1' |terraform state push -You can use it by modifying the "module.mymodule" to the path of the actual module you want to move resources to. You need the jq and uuidgen commands. Then do your move: terraform state mv resource_type.my_resource module.mymodule.resource_type.my_resource # Now that works
terraform init # to download the null provider, that's needed at this point
terraform apply # That will delete the null resource, since it's not present in the codeNow, that is still a horrible hack :). Dear Hashicorp, this bug is breaking basically all module-related refactoring possibilities, I really think it needs love fast ! |
|
If you use the workaround provided by @navaati, you can use the following command to remove the dummy |
|
@jbardin Why was this issue closed? I am still seeing this behavior in Terraform 0.12.5. Either this defect still exists, or the documentation should be updated to indicate that it is not possible. In my use case, I am trying to refactor a large module into sub-modules. I am trying to do something like: I get the following error: From the documentation:
|
|
Hi @jcarlson, the Close message above has a link to the PR that closed the issue, which was merged after 0.12.6. It will be included in the next release. |
|
Apologies, I missed that PR link. Thank you! |
|
hi I'm facing the same issue with terraform 0.12.6 tf state mv aws_iam_role.ecs_cloud_watch_read_role module.monitoring.module.iam.aws_iam_role.ecs_cloud_watch_read_role
Error: Invalid target address
Cannot move to
module.monitoring.module.iam.aws_iam_role.ecs_cloud_watch_read_role:
module.monitoring.module.iam does not exist in the current state.# the old state here
tf state show aws_iam_role.ecs_cloud_watch_read_role
# aws_iam_role.ecs_cloud_watch_read_role:
resource "aws_iam_role" "ecs_cloud_watch_read_role" {
arn = "arn:aws:iam::229482903727:role/ecsCloudWatchReadRole"
assume_role_policy = jsonencode(
{
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ecs-tasks.amazonaws.com"
}
},
]
Version = "2012-10-17"
}
)
create_date = "2019-08-15T08:09:15Z"
force_detach_policies = false
id = "ecsCloudWatchReadRole"
max_session_duration = 3600
name = "ecsCloudWatchReadRole"
path = "/"
tags = {}
unique_id = "AROATK3R7HCX65ATUVF7C"
}tf show tfplan
- aws_iam_role.ecs_cloud_watch_read_role
- aws_iam_role_policy.ecs_cloud_watch_read_policy
-/+ module.monitoring.aws_ecs_task_definition.z_grafana_td (new resource required)
~ module.monitoring.module.ecs_cluster.aws_launch_template.ecs_cluster_lt
# I created the new resource here
+ module.monitoring.module.iam.aws_iam_role.ecs_cloud_watch_read_role
+ module.monitoring.module.iam.aws_iam_role.ecs_efs_instance_role
+ module.monitoring.module.iam.aws_iam_role_policy.ecs_cloud_watch_read_policy
+ module.monitoring.module.iam.aws_iam_role_policy.ecs_rexray_efs_policy
+ module.monitoring.module.iam.aws_iam_role_policy.ecs_rexray_volume_policy
+ module.monitoring.module.iam.aws_iam_role_policy_attachment.ecs_for_ec2_role
+ module.monitoring.module.iam.aws_iam_role_policy_attachment.efs_read_only_access
tf --version
Terraform v0.12.6
+ provider.aws v2.24.0
+ provider.cloudflare v1.17.1 |
|
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. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Terraform Version
Terraform Configuration Files
A reference module can be as simple as:
Debug Output
Expected Behavior
Terraform 0.11.13 (and below) would move the resource to the module, assuming you provided the full path to the resource contained within the module, e.g.
module.foo.whatever_resource.resource_name.Actual Behavior
Terraform 0.12.0-rc1 errors out, stating that
module.foodoesn't exist in the current state. And that's true, it's not currently being tracked.Steps to Reproduce
terraform-12-rc1 initterraform-12-rc1 import github_team.foo SOME_TEAM_IDterraform-12-rc1 state mv github_team.foo module.foo.github_team.thisAdditional Context
N/A
References
N/A (I searched and didn't find anything; feel free to edit if reference issues are found)
The text was updated successfully, but these errors were encountered: