This adds retry logic to the amazon/chroot builder. The builder
intermittently fails when ec2conn shows the volume in the attached
state but calling Volumes[0].Attachments return an empty array. The
fix adds a retry logic for when Volumes[0].Attachments has len 0 sleep
for 2 seconds and retry up to 30 times.
When the Volumes[0].Attachments is empty I find within 5 seconds the
Volumes[0].Attachments contains the correct value.
The issue is reported in:
https://github.com/mitchellh/packer/issues/1854
This commit moves the Amazon builders of Packer away from the Hashicorp
fork of the goamz library to the official AWS SDK for Go, in order that
third party plugins may depend on the more complete official library
more easily.
mount /dev/xvdf /mnt/point
while for an HVM image that is attached to /dev/sdf, its mount command is
mount /dev/xvdf1 /mnt/point
so this code enabled that
This reduces the number of simultaneous packer runs possible significantly, but unless you are Netflix, who have Aminator anyway, this is probably never going to be an issue
According to be5adb92b5, the UploadDir
method supports two ways of copying depending on whether a trailing
slash is used:
src = "dir" -> dest/dir
src = "dir/" -> dest
On BSD-based systems (such as OSX, FreeBSD, etc.) the `cp -R` command
handles these two cases automatically. However, Linux treats "src/" and
"src" the same.
To support the trailing slash syntax portably, we can use:
src = "dir" -> dest/dir
src = "dir/." -> dest
This works on BSD and Linux. It is better than using wildcards as it
grabs hidden files as well.
This fixes#1196 that prevents the chef-solo provisioner from working
with the chroot builder.
It appears that the desired effect was to support
src = "dir" -> dest/dir
src = "dir/" -> dest
but cp -R already handles this, provided the trailing slash does not
get consumed by the shell.
The wildcard causes problems when multiple files match the
shell glob, e.g.
UploadDir("/tmp", "./salt*", [])
where my working dir contains
- salt
- salt-foo
will error.
* Single quotes around chroot command cause it to fail.
* The chroot command also gets passed through the CommandWrapper template, so having sudo would clash with however the user wants to run it.
* Fix spelling mistake.
/cc @mwhooker - I changed the interface up a bit to return an error,
since things should return errors in Go (the ui.Error bit was kind of
ghetto because it had no way to bubble that error up except through the
UI).
Using this, I made it so that the communicator uses both a
CommandWrapper and ShellCommand with chroot so that the chroot commannd
is also wrapped (it wasn't before).
I think the functionality of all this is the same but I'd love if you
could look it over and make sure.