Moving or renaming a data source resource, resource listing in tfstate is misnamed.

[piomar]

When moving a data source resource with terraform state mv using the names provided in terraform state list, the resource names for data sources are not kept correct, listing it to be destroyed via terraform plan after the move.

Unsure if this is an issue with state list not listing a resource as a data source, or state mv being too literal with the renaming of a resource, without taking into account it's original name.

Terraform Version

Terraform v0.9.4

Affected Resource(s)

• data.* (Looks to affect all data resources)

Terraform Configuration Files

00_definitions.tf

provider "aws" {
  alias   = "us-west-2"
  profile = "profile"
  region  = "us-west-2"
}

variable "ami" {
  default = "CentOS Linux*"
}

01_data.tf

data "aws_ami" "centos7" {
  provider    = "aws.us-west-2"
  most_recent = true

  filter {
    name   = "name"
    values = ["${var.ami}"]
  }
}

Original terraform.tfsate https://gist.github.com/piomar/592e2d96233484cbf029892eb2e2702a

Post-move terraform.tfstate https://gist.github.com/piomar/bd8758b5493b4df20cad45d8e9705e40

Debug Output

https://gist.github.com/piomar/ead16268616512369ae83c230d71799c

Panic Output

None

Expected Behavior

terraform state mv should move the data source resource in the tfstate file correctly.

Actual Behavior

terraform state mv uses the name given in the command verbatim, causing the resource to be marked for destruction.

Steps to Reproduce

1. terraform apply
2. terraform state list
3. terraform state mv aws_ami.centos7 aws_ami.centos7-1 (name from terraform state list)
4. terraform plan

References

None.

[apparentlymart]

Hi @piomar! Sorry this didn't work properly.

It looks like Terraform got confused and turned the data resource into a managed resource during the rename.

That is certainly a bug, but note that the correct invocation of terraform state mv in this case would've been:

terraform state mv data.aws_ami.centos7 data.aws_ami.centos7-1

There's actually a couple different bugs packed in here:

• Terraform took a resource address for a managed resource (no data. prefix) and yet matched a data resource. This should've instead been an error, since there is no managed resource matching the given address.
• Terraform should generate an error if you try to move a data resource to the address of a managed resource.

Thanks for reporting this! For now, hopefully this issue can be avoided by explicitly including the data. prefix when moving/renaming data resources, but we should get the validation cases working here to avoid potentially-costly mistakes.

[gjacquet]

I actually ran into that issue trying to merge a state file into another one. I naively ran terraform state list and then terraform state mv each line. That resulted in a very messed up state file.

Is there a safe way to merge states until that issue is fixed?

[deitch]

Aha. Just came across this. Large and complex statefile, and I did exactly what @gjacquet did: tf state list and then tf state mv for each line. It didn't occur to me that the problem might be with tf state list, not the latter part (although I am unsure).

Is there a proper way to do tf state list?

[teamterraform]

@deitch For prioritizing this bug, could you confirm that this issue exists in 0.12?

[deitch]

Will do.

[deitch]

It looks like 0.12 does a correct output. This is true whether I use tf state list against a statefile generated via 0.11 but run tf state list with terraform 0.12 binary, or whether against a statefile generated cleanly by 0.12.

0.11:

$ tfenv use 0.11.14
[INFO] Switching to v0.11.14
[INFO] Switching completed
$ tf state list
aws_iam_user.test
template_file.username
$ tfenv use 0.12.3
[INFO] Switching to v0.12.3
[INFO] Switching completed
$ tf state list
data.template_file.username
aws_iam_user.test

Notice that it now prepends data. to data elements (a good thing).

A tf state mv seems to do the right thing, although it always is a challenge with it being too sensitive and wanting to replace resources.

[teamterraform]

Thanks for confirming, @deitch! Since this is fixed in 0.12 and we aren't planning any future 0.11 releases, I will close this issue now. I'm sorry that you ran across it recently.

[ghost]

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.