Terraform: aws_eip_association.eip_assoc: unexpected EOF (cannot reopen #7910)

[rainkinz]

Terraform Version

$ terraform -v
Terraform v0.7.7

Affected Resource(s)

aws_eip_association

Terraform Configuration Files

resource "aws_instance" "web" {
  ami = "${var.aws_ami_id}"

  instance_type = "m3.large"

  availability_zone = "us-east-1b"

  key_name = "${var.key_name}"

  iam_instance_profile = "Prod-Webserver"

  # TODO: Change to a VPC
  # vpc_security_group_ids = ["${aws_security_group.main_security_group.id}"]

  security_groups = ["redacted"]

  # The connection block tells our provisioner how to communicate with the 
  # resource (instance)
  connection {
    user = "someuser"

    # The connection will use the local SSH agent for authentication.
    private_key = "${file(var.private_key_path)}"
  }

  tags {
    Name = "web7"
  }

}

resource "aws_eip_association" "web7" {
  public_ip = "54.123.456.789"
  instance_id = "${aws_instance.web.id}"
}

Panic Output

crash.log: https://gist.github.com/rainkinz/8da26dd707c57cc26c71082017acb4f6

Expected Behavior

There should be no error.

Actual Behavior

Terraform crashes

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Running EC2. Trying to associate an existing EIP.

References

I've added the above information to https://github.com/hashicorp/terraform/issues/7910, but cannot reopen, so opened a new bug here.

• GH-7910

[kwilczynski]

@rainkinz hi there! I am sorry that you are having issues with this.

In the past, when @dvela2 reported the issue, it was proven to be very elusive. Perhaps since you have the same issue, we can now get to the bottom of it.

[rainkinz]

@kwilczynski Sounds good. Let me know what additional details you need.

[dvela2]

@kwilczynski any progress?

[nickmaccarthy]

I too am having the same issue. Has anyone made any progress on this? I have a pretty big deployment coming up and the use of EIP's is critical for us.

[EvilPlankton]

+1 for a fix to this. Current workaround puts our TF state in jeopardy.

[kwilczynski]

Hi there @rainkinz @dvela2 @rainkinz @nickmaccarthy @EvilPlankton!

I am sorry you are having issue with this.

The challenge for me to fix this - I cannot reproduce this. No matter what I do with my test AWS account, I am unable to trigger the same issues. Which means that I am unable to pin-point the code responsible for this, and thus fix it for all of you :(

I would most likely need to see this breaking when it happens i.e. when you can consistently reproduce this.

If anyone is willing to arrange for a Google Hangout or Zoom call so that we can troubleshoot this together, than I would be much obliged. Otherwise I am completely lost.

[nickmaccarthy]

@kwilczynski I can certainly do a hangout with you. Thinking on this during the weekend, it may only affect accounts that have 'classic' ability ( any AWS account created around 2013 and before ). It is consistently reproducible on my end however. Creating the EIP is fine, is the association that causes TF to crash. The 'id' for EIP is the actual IP address for a classic EIP, so I'm not sure if that is anything to consider? Just throwing spagetti at the wall. Anyways, if you want to do a hangout, you can hit me up a and we can figure it out from there.

[kwilczynski]

@nickmaccarthy hi there!

That might be indeed related to the classic (EC2 legacy) access, which is something I am unable to utilise for testing, since my personal account is from 2014 onwards. I suspect either a timing issue, or difference in API response (which would be odd, but not unheard of in terms of AWS).

Thank you! Your offer is very kind (the Hangout session). I will definitely drop you an e-mail to get an idea about when would be the best (due to travel I am in CET time zone at the moment).

[kwilczynski]

@nickmaccarthy hi there! I reached out via e-mail.

[kwilczynski]

@rainkinz @dvela2 @rainkinz @nickmaccarthy @EvilPlankton hi there!

A big _Thank You_ to @nickmaccarthy and @radeksimko for their assistance and help during the holiday time. Much appreciated and praiseworthy attitude.

The bottom of the project is lack of support for EC2 Classic in this particular resource. For accounts that are old enough to still have access to the EC2 Classic, when the resources are provisioned outside of the VPC, the API does not need to return an Association ID for the Elastic IP to EC2 Instance association, etc., which leads to nil value being passed for the response struct member, and in turn panic will happen.

After having a chat with @radeksimko, who also mentioned that he wanted to incorporate his Pull Request #7568 into the core at some point, making it easier to detect an account type, which would help to address EC2 Classic vs EC2 VPC-enabled issues in a nicer way. And there are other resources that suffer from lack of proper support and testing concerning EC2 Classic support.

At this time, without modifying aws_eip_association resource to work with two types, or perhaps adding an extra attribute to indicate what type of account it is (as the interim solution before @radeksimko's work can be added; and it would be definitely a clunky solution), or alternatively (as suggested by @nickmaccarthy) perhaps adding a resource with suffix __classic_ to work exclusively with EC2 Classic type Elastic IP might work.

For the time being I have no solution aside of possibly recommending shelling out to something like AWSCLI which could be used to add and/or modify such Elastic IP association. I am very sorry about this.

[hashibot[bot]]

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.