Packer: amazon-ebs: Get http://169.254.169.254/latest/meta-data/placement/availability-zone

Created on 13 Nov 2013 · 10Comments · Source: hashicorp/packer

packer 0.3.11 seems to have suddenly started throwing up this error _every_ time:

packer build -debug /tmp/dry-run.json
Debug mode enabled. Builds will not be parallelized.
amazon-ebs output will be in this color.

Build 'amazon-ebs' errored: Get http://169.254.169.254/latest/meta-data/placement/availability-zone: dial tcp 169.254.169.254:80: i/o timeout

==> Some builds didn't complete successfully and had errors:
--> amazon-ebs: Get http://169.254.169.254/latest/meta-data/placement/availability- zone: dial tcp 169.254.169.254:80: i/o timeout

==> Builds finished but no artifacts were created.

with the following template:

{
  "builders": [
    {
      "type": "amazon-ebs",
      "region": null,
      "source_ami": "ami-d1ce80b8",
      "instance_type": "m1.medium",
      "ssh_username": "root",
      "ssh_timeout": "5m",
      "ami_name": "resi-subown-aminate-66",
      "tags": {
        "created_at": "{{isotime}}"
      },
      "ami_regions": [

      ],
      "ami_users": [

      ]
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "script": "deploy/ami/install.sh"
    }
  ]
}

Source

jasond

Most helpful comment

ahhh. its my template.

without specifying the region, its trying to look it up.

( think it might be the same for anything else it needs to look up )

we are driving packer through a ruby wrapper, which picks up an environment variable to set the region in the template. alas, i must have grabbed a new shell somewhere along the way and not set the variable.

_sighs_ as you were...

jasond on 13 Nov 2013

👍4 ❤2

All 10 comments

should also add, this happens pretty much immediately - the url is one that a running instance should be able to hit to get info from inside aws.

oh and running on OSX 10.9

jasond on 13 Nov 2013

I ran Packer 0.3.11 about 10 minutes ago and didn't get this. Pretty weird...

@mwhooker Any thoughts?

mitchellh on 13 Nov 2013

i've re-run with packer 0.3.10 and same result.

next step .. reboot the machine ( clutching at straws...)

jasond on 13 Nov 2013

earlier in the day, it was all working fine, same versions of packer, etc.

it will toggle between 'no route to host' and 'io timeout' as the final message.

i'll give it another run tomorrow.

jasond on 13 Nov 2013

At times I have seen the meta-data take some time to become eventually consistent. Perhaps this is another case where an additional retry loop is required.

markpeek on 13 Nov 2013

ahhh. its my template.

without specifying the region, its trying to look it up.

( think it might be the same for anything else it needs to look up )

_sighs_ as you were...

jasond on 13 Nov 2013

👍4 ❤2

Oh I think I see what's happening.

You were running packer on OSX and it tried to hit the metadata service? Goamz may have changed recently changed so it responds with a different type of error https://github.com/mitchellh/goamz/blob/master/aws/aws.go#L180

We should probably make the error clearer

mwhooker on 14 Nov 2013

yeah, i trawled the web and found the goamz code that had the url, but couldnt work out why it was trying to get to the metadata service in the first place.

( a different build we have running using packer is running in aws, so comparing it with my local build on laptop was pretty confusing )

perhaps even getting the error message to add _why_ its looking up the metadata service ( in this case it was for the region ) might make it a bit more clear?

the fix for me obviously was to specify the region in the packer template, but all round was a bit confusing.

maybe make the region parameter mandatory?

jasond on 15 Nov 2013

@jasond thank you so for elaborating what caused this for you!
I just hit this with packer 0.7.5 on OS X 10.9 because i had a typo in the region shell variable. Error message is pretty misleading, maybe it is indeed a good idea to make this parameter mandatory now that more people start pushing via packer