lifecycle ignore_changes not working on aws_instance user_data

[nickithewatt]

Hi,

I currently have some terraform config which defines both an AWS instance as well as template which I use to provide input for user-data for cloud-init. I DO NOT want my instance to be recreated if the user_data changes (as this is by default only picked up the first time the instance launches in AWS, so any changes here are really irrelevant). I was trying to use the lifecycle ignore_changes config to do this however it does not appear to be doing what I would expect and lands up wanting to recreate my instance again anyway.

Before adding the lifecycle ignore_changes block, with the following definition:

# Template for user-data
resource "template_file" "mytemplate" {
    template = "${file("${path.module}/mytemplate.sh.template")}"
    vars {
        x                  = "${var.x}"
        y                  = "${var.y}"
    }
}

# Instance using template to supply user-data
resource "aws_instance" "ipa" {
  ami = "${var.ami-name}"
  instance_type = "${var.instance-type}"
  ...
  user_data = "${template_file.mytemplate.rendered}"
}

a terraform plan -module-depth=-1 results in:
(Note: explicit mention of forcing a new resource due to change in user_data which is expected)

-/+ aws_instance.ipa
    ami:                        "ami-xxxxxx" => "ami-xxxxxx"
    availability_zone:          "eu-west-1b" => "<computed>"
    source_dest_check:          "true" => "1"
    ...
    user_data:                  "32d90588844152eeb595a77d9995da028cec6601" => "04b4e21559023d475959cbc4c058ff4df50ae60a" (forces new resource)

However adding the lifecycle ignore_changes block as follows:

# Instance using template to supply user-data
resource "aws_instance" "ipa" {
  ami = "${var.ami-name}"
  instance_type = "${var.instance-type}"
  ...
  user_data = "${template_file.mytemplate.rendered}"
  lifecycle {
    ignore_changes = ["user_data"]
  }  
}

And running a terraform plan -module-depth=-1 correctly indicates (at least at initial face value anyway) that it is ignoring the user_data field as it is not even displayed in the output with the "forces new resource" comment HOWEVER terraform still (via the -/+) indicates it is actually going to destroy and recreate the instance, i.e. I get the following:

-/+ aws_instance.ipa
    ami:                        "ami-xxxxxx" => "ami-xxxxxx"
    availability_zone:          "eu-west-1b" => "<computed>"
    source_dest_check:          "true" => "1"
    ...

Note: if the template does not change, then this instance is not flagged for destroy and recreate - In other words, the marking of the instance for destroy and recreate is not because of changes to any other fields (outside of the user_data template one which should, in theory be ignored)

[erkolson]

Ugh, this is kind of frightening. What version are you using?

[nickithewatt]

This still happens on 0.6.12.

I think the issue has something to do with the fact that the user_data is being created based on the rendering of a template resource (user_data = "${template_file.mytemplate.rendered}"). In this setup a change does indeed occur against the template resource, e.g. a change to a variable used as input to the template, which correctly results in the rendering of a different value from the template resource. Even so, as I have specified that the VM should ignore this field, I would expect this to be honoured - even though it's computed based on a template resource

[fahran]

+1

[rowleyaj]

@phinze commented on #3528:

looks like ForceNew attributes aren't being properly handled

[nickithewatt]

Yes this looks like the same problem, probably worth closing this issue, and tracking it there. I shall update that ticket

[phinze]

Merging this issue back down with #3528 👍 we'll get this fixed up soon!

[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.