You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to destroy aws_ebs_volume created with help of for_each, related and not related to it aws_volume_attachment resources also marked for remove
Only aws_ebs_volume and related attachment should be removed. Other attachments that related to another volumes should stay untouched.
Actual Behavior
Terraform will perform the following actions:
# aws_ebs_volume.volume["tst-instance-01-vol-sdf"] will be destroyed
- resource "aws_ebs_volume" "volume" {
# aws_volume_attachment.volume_attachment["tst-instance-01-vol-sdf"] will be destroyed
- resource "aws_volume_attachment" "volume_attachment" {
# aws_volume_attachment.volume_attachment["tst-instance-01-vol-sdg"] will be destroyed
- resource "aws_volume_attachment" "volume_attachment" {
# aws_volume_attachment.volume_attachment["tst-instance-02-vol-sdf"] will be destroyed
- resource "aws_volume_attachment" "volume_attachment" {
# aws_volume_attachment.volume_attachment["tst-instance-02-vol-sdg"] will be destroyed
- resource "aws_volume_attachment" "volume_attachment" {
Steps to Reproduce
terraform init
terraform apply
terraform plan -destroy -target='aws_ebs_volume.volume["tst-instance-01-vol-sdf"]'
The text was updated successfully, but these errors were encountered:
Unfortunately Terraform is working as designed here, because it's noticing that aws_volume_attachment.volume_attachment depends on aws_ebs_volume.volume in order to get the map of aws_ebs_volume.volume instances and then select the each.key element from it.
It sounds like the behavior you were expecting here -- reasonably -- is that Terraform would understand that each.key dynamically selects only a specific instance and thus create fewer dependencies. That is not how Terraform's graph model works today (the planning graph is in terms of whole resources rather than resource instances), so we asked the bot to mark this as an enhancement to make Terraform use a more granular dependency resolution mechanism.
That is not an easy change, so this is unlikely to be implemented in the near term. Note that -target is provided only for exceptional circumstances, such as recovering from mistakes or working around Terraform limitations. It is not recommended to use -target for routine operations, since this can lead to undetected configuration drift and confusion about how the true state of resources relates to configuration. For that reason, we do not tend to prioritize -target-related requirements when considering future architectural changes.
@teamterraform please consider a use case for a -target and resources provisioned with for_each loops:
Let's say you have a code pattern that provisions 100 vms with disk attached. And you need to re-create only on of them. So what do you do? You invoke destroy with -target and target this one vm . What will terraform do ? - Destroys vm , its disk attachment and all other attachments of disks for other 99vms... How can i achieve the goal of re-creating one resource and not impacting the others without -target ?
When trying to destroy
aws_ebs_volume
created with help of for_each, related and not related to itaws_volume_attachment
resources also marked for removeTerraform Version
Terraform Configuration Files
Expected Behavior
Only
aws_ebs_volume
and related attachment should be removed. Other attachments that related to another volumes should stay untouched.Actual Behavior
Steps to Reproduce
The text was updated successfully, but these errors were encountered: