Terraform-provider-aws: TF plan & apply not seeing correct associate_public_ip_address

Created on 13 Jun 2017  ·  9Comments  ·  Source: hashicorp/terraform-provider-aws

_This issue was originally opened by @Gary-Armstrong as hashicorp/terraform#9811. It was migrated here as part of the provider split. The original body of the issue is below._


The symptom is that I get -/+ aws_instance.stage on each exec of plan and apply. Changing associate_public_ip_address from true to false did recreate the instance as expected, but subsequent plans and applies ALSO recreated the instance due to associate_public_ip_address: "true" => "false" (forces new resource). Naturally I inspected state and find that it correctly contains "associate_public_ip_address": "false".

Perhaps a more pertinent detail is that I converted from 0.6.16 to 0.7.8 on this run, after which it began acting as described. I'm not sure if the conversion is related but since this same code does not behave this way in an existing 0.7.7 env, I'm going to start off looking at changes in the latest version.

Terraform Version

0.7.8 & 0.8.1

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

associate_public_ip_address = false
The tf code has not changed, and in fact the same symlinked file performs as expected in 0.7.7

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://gist.githubusercontent.com/Gary-Armstrong/abee399a98d8f297ad149b72d77eac3b/raw/f131e32dff6f13f4bd139a41a929fa32b88001f9/TF%25200.7.8%2520Adventure%2520in%2520Plan+Apply%2520Unexpectations

Expected Behavior

I expected after the initial recreation of the instance that it would not happen again.

Actual Behavior

TF will plan and apply a -/+ action on the instance, citing the same change reason.

Steps to Reproduce

  1. terraform apply
    You might want to tell me what additional information you need.

Important Factoids

Moved from 0.6.16 to 0.7.8, while other envs in this repo use 0.7.7 instead.

bug servicec2 stale

Most helpful comment

What's the status of this? it's blocking for us.

All 9 comments

I'm also experiencing this issue with version 0.9.11.
What I see happenings is that every plan wasn't to create a new resource:
associate_public_ip_address: "true" => "false" (forces new resource)

As a temp fix what I found is that if I set associate_public_ip_address to false the first time to reallocate an EIP to a new instance then set associate_public_ip_address to true it doesn't rebuild it.

This issue was also noted in hashicorp/terraform#9811

resource "aws_instance" "ssh-bastion" {
...
associate_public_ip_address = false
}

resource "aws_eip_association" "ip-bastion" {
instance_id = "${aws_instance.ssh-bastion.id}"
allocation_id = "${aws_eip.ssh-bastion.id}"
}

resource "aws_eip" "ssh-bastion" {
vpc = true
}

Thanks,
Fred

Also have the issue.

For me specifically, I'm adding an EIP to an existing terraform-tracked instance (via aws_eip_association). It works on initial apply, but every subsequent terraform plan reports:

-/+ module.loadbalancer.aws_instance.instance
      associate_public_ip_address:            “true” => “false” (forces new resource)

Following the temp fix from @fstuck37 also works for me, but this is not a feasible workflow for our scenario.

My current plan is to use the workaround @trbs mentioned on the original thread (https://github.com/hashicorp/terraform/issues/9811#issuecomment-258270103)

    lifecycle {
        ignore_changes = [
             "associate_public_ip_address",
        ]
    }

To just ignore changes to this property.

Hi @podung

Are you still having the issue with TF 0.10.2?
Thanks!

Yes, this issue still occurs.

-/+ module.solr_slave_1a.aws_instance.generic (new resource required)
      id:                                        "i-xxx" => <computed> (forces new resource)
      ami:                                       "ami-061b1560" => "ami-061b1560"
      associate_public_ip_address:               "false" => "true" (forces new resource)

This is easy to reproduce. Just stop an instance and terraform plan will want to recreate it, even after you restart it.

What's the status of this? it's blocking for us.

Im still hitting this on

justin@justin-ThinkPad-T560 ~/Documents/projects/tf_demo/sample/openvpn $ terraform --version
Terraform v0.11.3

  • provider.aws v1.10.0
  • provider.template v1.0.0

I create an eip, instance and an allocation. Works fine. When i do another plan it wants to remove and recreate the instance.

-/+ aws_eip_association.openvpn_eip_assoc (new resource required)
id: "eipassoc-050de3f9" => (forces new resource)
allocation_id: "eipalloc-cceae7fa" => "eipalloc-cceae7fa"
instance_id: "i-0de835f089689df62" => "${module.openvpn.id[0]}" (forces new resource)
network_interface_id: "eni-aecbee2e" =>
private_ip_address: "10.80.2.107" =>
public_ip: "35.173.81.128" =>

-/+ module.openvpn.aws_instance.this (new resource required)
id: "i-0de835f089689df62" => (forces new resource)
ami: "ami-8bb540f6" => "ami-8bb540f6"
associate_public_ip_address: "true" => "false" (forces new resource)

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings