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

lifecycle ignore specific attributes #19958

Closed
attenda-johnmcmillan opened this issue Jan 10, 2019 · 3 comments
Closed

lifecycle ignore specific attributes #19958

attenda-johnmcmillan opened this issue Jan 10, 2019 · 3 comments

Comments

@attenda-johnmcmillan
Copy link

attenda-johnmcmillan commented Jan 10, 2019

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

jbardin commented Jan 10, 2019

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.

@jbardin jbardin closed this as completed Jan 10, 2019
@mingfang
Copy link

mingfang commented Mar 12, 2019

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

@ghost
Copy link

ghost commented Mar 29, 2020

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.

@hashicorp hashicorp locked and limited conversation to collaborators Mar 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants