terraform-provider-random
terraform-provider-random copied to clipboard
Random pet doesn't support import
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
-
terraform apply
- `terraform state rm random_pet.asdf
- 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.
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
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.
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