Re: [vagrant-up] Bad Request using vagrant-aws

[Robert Fynes]

As mentioned in the github post in the link above, in this particular case my problem was that I was trying to launch an instance-store AMI on a t1.micro, which you can't do.

Switching to an m1.small fixed it (using an EBS volume with the micro would have worked too).

On 4 June 2013 18:55, Robert Fynes <fyn...@gmail.com> wrote:

Has anyone ever come across the following error after running vagrant up --provider=aws when using the vagrant-aws plugin:

/home/rfynes/.vagrant.d/gems/gems/excon-0.22.1/lib/excon/middlewares/expects.rb:10:in `response_call': Expected(200) <=> Actual(400 Bad Request) (Excon::Errors::BadRequest)

It's not an invalid creds issue, the specifed AMI is valid and the key-pair name/location is correct. Here's a look at my Vagrantfile for the aws provider:

Vagrant.configure("2") do |config|

  config.vm.box = "aws-dummy"

  config.vm.provider :aws do |aws, override|

    aws.access_key_id = "..."

    aws.secret_access_key = "..."

    aws.keypair_name = "vagrant-aws"

    aws.region = "eu-west-1"

    aws.instance_type = "t1.micro"

    aws.ami = "ami-605c5314"

    override.ssh.private_key_path = "~/.ssh/vagrant-aws.pem"

  end

end

I'm just testing, so the Vagrantfile for the project itself is minimal, as follows:

Vagrant.configure("2") do |config|

    config.vm.box = "aws-dummy"

end

This appears to be the exact same problem that these guys are having here:

https://github.com/mitchellh/vagrant-aws/issues/75

...and the output linked to in the question is the same as my output (within reason: AMI, region etc.)

Any help is appreciated.

-Rob

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Torben Knerr]

I had the same issue, for me it was a typo in the keypair name. Also check that the security groups (if any) exist.

HTH, Torben

[JD Harrington]

I ran into an issue with test-kitchen a week or 2 back that I believe produced the same error. In test-kitchen, the default availability_zone gets set to us-east-1b and, on my account, us-east-1b is not available because it's at capacity or whatever, so I can't provision in it. Setting another AZ works fine.

Looking quickly through the vagrant-aws code, it looks like there's no default AZ set, so it seems unlikely that you're hitting the same thing, but might be worth explicitly setting an AZ that you know works for you just to eliminate that possibility.

[david conner]

i'm running into the same error, but it's as if AWS doesn't recognized my key or something...

Here's what i posted in IRC:

01:11 < dcunit3d> when i try to boot my box via AWS, it's as if AWS is not looking in the right place for the data that's clearly shown in my dashboard

01:11 < dcunit3d> i've tried just working with the EC2 Dashboard, creating a keypair there

01:11 < dcunit3d> i've tried adding a user through the IAM dashboard

01:12 < dcunit3d> when i set my security group that is *clearly* defined in the EC2 Dashboard, i get the message: <Message>The security group 'vagrant' does not exist</Message>

01:13 < dcunit3d> when i leave my security group definition off, i get the response: <Message>The key pair 'vagrant' does not exist</Message>

01:13 < dcunit3d> there are at least 3 active github issues where people are experiencing this problem.

01:13 < dcunit3d> can anyone help me?

[Robert Fynes]

Although my original problem causing me to see the BadRequest errors was related to an incorrect instance type with my chosen AMI, I recently came up against the same error for a seemingly different problem.

In the hope that it'll benefit anyone else, the problem was because my root directory contained .vagrant/machines/default/aws/id (a file containing an AWS instance ID).

The .vagrant dir and that 'id' file are automatically generated after a 'vagrant up'. I was getting the error because I was trying to vagrant up in a root directory I had copied from another location (which had previously had a 'vagrant up' run in it, producing the id file).

It obviously causes a conflict. Remove the .vagrant directory prior to 'vagrant up'.

[liam buell]

i was having the same problem and what resolved it for me was doing ec2-add-keypair <nameofyourpemfile>.pem,  for some reason stuff just wasn't connecting and aws wasn't linking the keypair.pem