Random pet doesn't support import

[cdobbyn]

Terraform Version

I was using 0.14.11 but this behaviour is present in all versions (including 1.x)

Affected Resource(s)

• random_pet

Terraform Configuration Files

resource "random_pet" "asdf" {}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

You should be able to terraform state rm this resource and then import it elsewhere as long as you have some kind of unique id to import it on the other side.

This is a problem because if you create other resources using the random_pet name you can't simply move them around or between terraform states, you need to actually completely recreate them.

Actual Behavior

There is no import functionality for random_pet.

Steps to Reproduce

1. terraform apply
2. `terraform state rm random_pet.asdf
3. Try to import it back. Notice there's no documentation, try terraform import random_pet.asdf asdf and get a message saying the resource doesn't support import.

Important Factoids

n/a

References

I couldn't see any referencing this specifically.

[n1ngu]

A mitigation is to ignore changes for the attribute where the random_pet id being used. E.g.

resource "random_pet" "name" {}

resource "example" "this" {
  name = random_pet.name.id

  lifecycle {
    ignore_changes = [
      # Because https://github.com/hashicorp/terraform-provider-random/issues/184
      name,
    ]
  }
}

As long as that entity truly can't be renamed without recreation, this should be save. E.g. an aws_db_instance

[djaboxx]

you can move multiple resources between statefiles. moving both the resource and the random_pet to the new statefille will (in a lot) of cases be better than ignoring changes to the random pet. A lot of times random_* is used to provide uniqueness to names. if the name change is ignored due to ignore_changes, then managing it becomes a little trickier or at least takes more operations to trigger a new resource name due to update of random_pet.

If you move the random_pet and the resource, you can simply taint the random_pet, and that will trigger both a new unique name to be generated, as well as trigger a rebuild of the affected resource. And if you have multiple resources that all use the same random_pet to somehow signify that these resources belong together in a logical grouping, then it's even more important to be able to refresh all of them with the one taint of the random_pet rather than having to taint all individual resources of the logical grouping.

Given that this is a logical resource in Terraform and not tied to anything that lives outside of it, it would make sense that if you state rm it will be gone. The workaround is to have versioned statefiles, and state mv from previous statefile to new statefile. Just had to do this in Terraform Enterprise today.

it appears that a PR with the import was in fact merged, so in future versions this wont be an issue. But for now, this seems to work.

[fabiopaiva]

Would be great if this feature was available. Meanwhile, here is a workaround

Run Terraform apply with target to create your random_pet resource

terraform apply -target random_pet.random

Pull the state (if remote)

terraform state pull > state.json

Change the random_pet attribute id and increase the state serial number

{
  "version": 4,
  "terraform_version": "1.8.5",
  "serial": 2, // change here
  "lineage": "5e414ec3-7b70-236f-3f3f-be211bc265d2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "random_pet",
      "name": "random",
      "provider": "provider[\"registry.terraform.io/hashicorp/random\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "precise-feline", // and here
            "keepers": null,
            "length": 2,
            "prefix": null,
            "separator": "-"
          },
          "sensitive_attributes": []
        }
      ]
    }
  ],
  "check_results": null
}

Push the state

terraform state push state.json