provider/aws: Error when unable to find a Root Block Device name

[catsby]

Fixes #2633 by returning an error if we can't find a Root Block Device

With a config like this (using an ami that is Instance backed):

provider "aws" {
    region = "us-west-2"
}
resource "aws_launch_configuration" "foobar" {
    name = "root_ami_thing"
    image_id = "ami-3fd3e90f"
    instance_type = "t2.micro"
    key_name = "packerkeything"

    root_block_device {
        volume_type = "gp2"
        volume_size = "64"
    }
}

resource "aws_autoscaling_group" "bar" {
  availability_zones = ["us-west-2a"]
  name = "foobar3-terraform-test"
  max_size = 2
  min_size = 0
  health_check_grace_period = 300
  health_check_type = "ELB"
  desired_capacity = 2
  force_delete = true
  termination_policies = ["OldestInstance"]
  launch_configuration = "${aws_launch_configuration.foobar.name}"
}

Now produces error:

Error applying plan:

1 error(s) occurred:

* [WARN] Error finding Root Device Name for AMI (ami-3fd3e90f)

Instead of the error shown in #2633

[catsby]

cc @phinze to double check that erring there is reasonable

[phinze]

In the linked issue the problem was a bad AMI ID, which means we would have hit the early nil return up on L735.

We specifically added that "no error when AMI not found" thingy in #1250 to fix unrecoverable error states because it was being hit in Read.

So we need to figure out how we can maintain the "allow users to correct bad AMIs" while still getting a specific error message when they specify one.

[catsby]

In the linked issue the problem was a bad AMI ID, which means we would have hit the early nil return up on L735.

Let's sync up to discuss. The issue I was debugging (and the only way I could repo the source issue) did not trigger L735; there was an image, but there was no root device matching in the lines above this. I couldn't use an AMI that didn't exist; TF returned an error before this point. I'll double check though...

[catsby]

For example, when I use a bad AMI in this context (Launch Configuration):

* InvalidAMIID.Malformed: Invalid id: "ami-nopenope"
    status code: 400, request id: []

[catsby]

@phinze did you see my updates here? Hopefully they made sense, let's sync up and see what we need to do

[phinze]

@catsby ah okay. so if we can verify that these steps still work:

• create ami
• create instance from AMI
• delete ami
• terraform refresh should not error

If that still is the case, then we're good to go.

[catsby]

terraform refresh should not error

It does not error... but a Launch Configuration will show a -/+ , since the AMI no longer exists ...

[phinze]

Commented inline - I think we'll need to dig into this.

[catsby]

Pulling this in

[ikalinin]

This change makes it impossible to use instance-store backed Amazon Linux images since they don't have a root device name on them. Please consider rolling this change back and finding another solution for #2633.

[catsby]

Hey @ikalinin – sorry for the trouble here! Do you have an example configuration for me to test out? I think we can avoid this error by checking the image.RootDeviceType and only throwing an error if is of type ebs, but I'm not entirely sure what the behavior should be for instance-store backed AMIs. Can you help me get this right?

I was able to reproduce the error using AMI ami-961bfaa5, an Ubuntu Trusty in the us-west-2 region. What I'm unsure about is the root_block_device mapping I should have, and what Terraform should do in this case

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