Unable to 👍 - Allow interpolations in lifecycle attributes

[joe-a-t]

Terraform Version

v1.4.5

Terraform Configuration Files

variable "prevent_destroy" {
  default = true
}

resource "null_resource" "main" {
  lifecycle {
    prevent_destroy = "${var.prevent_destroy}"
  }
}

Debug Output

│ Error: Variables not allowed
│ 
│   on main.tf line 7, in resource "null_resource" "main":
│    7:     prevent_destroy = var.prevent_destroy
│ 
│ Variables may not be used here.
╵
╷
│ Error: Unsuitable value type
│ 
│   on main.tf line 7, in resource "null_resource" "main":
│    7:     prevent_destroy = var.prevent_destroy
│ 
│ Unsuitable value: value must be known

Expected Behavior

I should be able to 👍 #3116 so that it can get properly prioritized to address this issue since it is a huge issue for a ton of people and the root of many many many other issues like hashicorp/terraform-provider-google#10168

Actual Behavior

Unable to 👍 that issue for the last 6 years so it looks like no one cares about the issue when it would most likely have the most 👍 of any Terraform issue if it was possible for users to 👍 it.

Steps to Reproduce

1. terraform validate

Additional Context

No response

References

• Cannot use interpolations in lifecycle attributes #3116
• Make it harder to destroy resources #24658
• "Variables may not be used here" for prevent_destroy #22544
• Add deletion_protection argument to google_container_cluster terraform-provider-google#10168
• Add deletion_protection to google_storage_bucket terraform-provider-google#7868
• [Provider: google-cloud] deleting an attached disk should not be possible terraform-provider-google#2078
• Add deletion_protection argument to google_secret_manager_secret terraform-provider-google#13661

[jbardin]

Hi @joe-a-t!

Thanks for compiling these issues. The original issue #3116 is probably no longer relevant as written -- interpolation is possible and used within lifecycle, but how it's used depends on each individual feature of a resource's lifecycle. Asking for interpolation for lifecycle in general is not going to effectively change anything.

It seems you are mostly concerned with prevent_destroy specifically, and one reason that has not changed is because it cannot do what the majority of users want it to do regardless of the ability to interpolate the value. Controlling how something is destroyed from the config doesn't work when that configuration can be removed entirely. If better control over the ability to destroy a resource is what you're after, #22544 covers this (and already shows a lot of support), but I think #24658 is probably where users should indicate their support for a more useful feature in general (or with the individual provider issues where that is applicable, since absolute control can only ever be applied outside of Terraform).

Since there is no specific bug to address here, I'm going to close the issue. If you have other concerns about enhancements which are not addressed by existing issues already, we can handle those individually in separate issues.

Thanks!

[joe-a-t]

@jbardin can you add a comment to #3116 pointing at the other issues? If you think 3116 is entirely invalid as written, then it should probably also get closed with pointers to the successive issues.

Right now, if you find #3116, it is impossible to find any of the other issues like #22544 that have sprung out of it because, given how the issue is locked, GitHub no longer adds a link to any other issue that references it so it's just a super frustrating black hole user experience.

Also I added this info to #22544 (comment).

[crw]

Yes, I have closed #3116 (comment)

Thanks for kicking off this discussion @joe-a-t. We really appreciate it, and appreciate your robust dive into the relevant references.

[github-actions]

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.