lifecycle ignore specific attributes

[attenda-johnmcmillan]

Current Terraform Version

Terraform v0.11.8
+ provider.aws v1.54.0
+ provider.template v1.0.0

Use-cases

We recently had to restore an EBS volume to an EC2 instances that had been deployed in terraform. This now means subsequent terraform plan/apply highlights that the instance in question will be destroyed and recreated - we don't want to do this.

We can workaround this at present in one of two ways, however these aren't appropriate in all the environments we manage and therefore I'd like to request an approach that would scale better in ours (and hopefully others') use cases.

Attempted Solutions

The original code was:

  ebs_block_device {
    device_name = "xvdd"
    volume_type = "gp2"
    volume_size = "900"
    encrypted = "true"
  }

The following workaround is effective in this particular environment where instances are individually defined:

  ebs_block_device {
    device_name = "xvdd"
    volume_type = "gp2"
    volume_size = "900"
    encrypted = "true"
    snapshot_id = "snap-xyz123redacted"
  }

However we have many other environments where we've used 'count' to spin up X number of instances and the above approach won't (easily) work there.

Another approach, which we'll use for the time being, is to ignore all ebs_block_device changes i.e.

lifecycle {  ignore_changes = "ebs_block_device" }

However that feels a little excessive. We'd like to be aware of other ebs_block_device changes that crop up if and when they do.

Proposal

What would be really nice would be to ignore only changes to snapshot id, I imagine it to look something like this:

lifecycle {  ignore_changes = "ebs_block_device.snapshot_id" }

e.g. terraform wouldn't care about the changing snapshot id but would care if volume_size or delete_on_termination changed.

Is this remotely possible?
Sorry if this is similar to requests you've had before - I did search through existing bugs & feature requests and while I saw a few talking about behaviour of ignore_changes - i couldn't see anything that matched the above scenario.

References

[jbardin]

Hi @attenda-johnmcmillan,

Thanks for filing the issue.
We have a few versions of this open already, like #6632 and #5666, so I'm going to close this in preference to the existing issues.

However, even with a proposed change to allow some sort of attribute addressing within ignore_changes, that won't directly apply to ebs_block_device attribute, because those are a set type which is not addressable. While there's some relevant discussion over in #9693, it's really going to rely on the provider changing the resource itself to allow for addressing of that particular attribute.

[mingfang]

I think this ticket is better than #6632 and #5666 since it more accurately describe the problem.

[ghost]

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.