This should fix it, but I haven't been able to test it because I'm having problems connecting to EC2 instances once they start.

Minor update to patch to pass cloud provider string to workers for installation script. Tested (with WHIRR-107 too) and manually checked that data was being stored on /mnt on EC2.

there's another approach we could use.

once the template is built, look at template.hardware.volumes. In ec2, this has the exact mount points for the ephemeral and ebs volumes attached

Adrian - yes, this is definitely a better approach - thanks for pointing it out. I'm tempted to commit the current patch as an interim fix and open a new JIRA to take advantage of the Volume objects (this might tie in with adding EBS support too). Thoughts?

I'm ok with this for a bug fix.

Here's more for the more complete issue:

it looks like alestic and rightscale images mount the first ephemeral disk onto /mnt. According to the amazon linux guide:
"The ephemeral drive ephemeral0 is mounted in /media/ephmeral0 only on S3 backed AMIs."

When we address this holistically, we may need to have a script that arranges the fstab and formats volumes accordingly, possibly using lvm or something to span disks together. Then, we can have a clear mount setup that whirr is authoritative for.

my 2p.

I've just committed this.

I opened WHIRR-111 for the larger issue.

my 2p.

Glad to see you're using the local currency!