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

Random pet doesn't support import #184

Open
cdobbyn opened this issue Nov 7, 2021 · 2 comments
Open

Random pet doesn't support import #184

cdobbyn opened this issue Nov 7, 2021 · 2 comments

Comments

@cdobbyn
Copy link

cdobbyn commented Nov 7, 2021

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.

wakeful added a commit to wakeful/terraform-provider-random that referenced this issue May 23, 2022
wakeful added a commit to wakeful/terraform-provider-random that referenced this issue May 23, 2022
wakeful added a commit to wakeful/terraform-provider-random that referenced this issue Jun 8, 2022
wakeful added a commit to wakeful/terraform-provider-random that referenced this issue Oct 22, 2022
@n1ngu
Copy link

n1ngu commented Feb 23, 2023

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
Copy link

djaboxx commented Feb 28, 2023

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.

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

No branches or pull requests

3 participants