Verbose error message

[millisami]

This is my first vagrant up --provider=aws cmd and it fails but doesn't show info about what exactly went wrong even with the VAGRANT_LOG=debug set.

This is the log at https://gist.github.com/millisami/5650122

What is the exact error that is failing this?

[alistairstead]

I'm experiencing the same issues.

Does the API call get logged as that could help diagnose if it is a bug or a credential error

[millisami]

@alistairstead And how do I verify that whether its logged-in or its a creds error?

[alistairstead]

That is my question. If the plugin was updated to log the API call structure at a DEBUG level then it could be used to debug the problem manually.

[fynesr]

I'm also having the same problem.
Did either of you guys find a solution?

[fynesr]

I've actually got it working now.
The problem was that I was requesting a t1.micro but the AMI that I wanted uses the instance store, as opposed to EBS. And you can't use t1.micro with instance store volumes.

Changing the instance type to m1.small fixed it, and I suppose picking an EBS AMI would have worked with a t1.micro too.

But the "Bad Request" error message is vague, so there may be other possible causes for that particular response from AWS.

[alistairstead]

I still have issues. It seems it is a problem with the credentials or configuration for EC2 API. However the error output is less than helpful. This seems to be the result of a regression in fog described here: fog/fog#1838

Once fog is updated can this version be pulled into Vagrant?

[bartclarkson]

+1

I've been messing with the Type. Initially I was using

aws.ami = "ami-70f96e40"
aws.instance_type = "t1.micro"

In the spirit of Doing It Like the ReadMe, I did it just like the ReadMe. No dice. Here's the first part of the stack.

[default] Launching an instance with the following settings...
[default]  -- Type: m1.small
[default]  -- AMI: ami-7747d01e
[default]  -- Region: us-east-1
[default]  -- Keypair: staging
/Users/bart/.vagrant.d/gems/gems/excon-0.22.1/lib/excon/middlewares/expects.rb:10:in `response_call': Expected(200) <=> Actual(403 Forbidden) (Excon::Errors::Forbidden)
...

So, yeah, I could have any number of things messed up. But there's no way to know which. I'll hammer on it for awhile longer. Then I'm just going to handle provisioning differently, which would be a bummer.

[SebTardif]

Looks like the fog bug is fixed, so we should be pulling this in, see fog/fog#1832

[alexturpin]

This is definitely a must have. I had to try to launch an instance with the PHP API to be able to check what the error message was with the parameters I was giving it, instead of a simple "Expected(200) <=> Actual(400 Bad Request)"

[ErisDS]

Also running into this issue, please pull in the fix.

[nanounanue]

Any news about this problem?

I have exactly the same problem...

[millisami]

Is it resolved and released in rubygems??

[dcunited001]

yeh i'm getting this error too. it's vague though. i usually use pry to troubleshoot this stuff, but i can't require the gem. at least not in the Vagrantfile.

[fynesr]

I came up against this problem again (changing the instance type, as I mentioned earlier, fixed it for me the first time).

This time, I discovered that the problem was because I was trying to vagrant up in a directory that I had copied from another location, which I had already vagrant up'd in.

This meant that my new directory also included the .vagrant dir that is automatically generated after running vagrant up. This directory contains a file called 'id' that contains the ec2 instance ID of the instance that has been launched. I'm assuming the presence of this file is what was causing the error, but I didn't look into it further. Anyway removing the dir fixed it, so beware.

I'm sure there's all sorts of scenarios that could produce this error message, so this needs to sorted.

[dcunited001]

It'd be nice if the actual amazon error bubbled up. I got the error bc I configured the wrong region. I thought I was us-west-1 but my instances were in us-west-2.  From: fynesrSent: Thursday, July 18, 2013 10:51 AMTo: mitchellh/vagrant-awsReply To: mitchellh/vagrant-awsCc: DCSubject: Re: [vagrant-aws] Verbose error message (#75)I came up against this problem again (changing the instance type, as I mentioned earlier, fixed it for me).

This time, I discovered that the problem was because I was trying to vagrant up in a directory that I had copied from another location, which I had already vagrant up'd in.

This meant that my new directory also included the .vagrant dir that is automatically generated after running vagrant up. This was the cause of the error, so beware.

I'm sure there's all sorts of scenarios that could produce this error message, so this needs to sorted.

—Reply to this email directly or view it on GitHub.

[dkd]

Not all ami are available in the different regions. check this in the AWS console.

[tralamazza]

Version 0.3.0 bubbles up Excon::Errors

[millisami]

Why is @mitchellh so silent on this issue?

[mitchellh]

@millisami The maintainer of this repository is @tralamazza. I mostly silently watch over this repo and watch the commits but I'm very happy with @tralamazza's decisions and direction. He is the voice here.

[tralamazza]

@millisami did you try version 0.3.0?

@mitchellh thanks ^^

[miguno]

Bump. Any feedback on whether (and if so, when) this improvement could be integrated into vagrant-aws?

[kenorb]

Is this error still valid?