# Unable to attach ebs block in aws

**URL:** <https://discourse.chef.io/t/unable-to-attach-ebs-block-in-aws/7997>\
**Category:** Chef Infra (archive)\
**Created:** [March 16, 2016, 3:37pm UTC](https://discourse.chef.io/t/unable-to-attach-ebs-block-in-aws/7997 "2016-03-16T15:37:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![phanikumar](https://avatars.discourse-cdn.com/v4/letter/p/ecc23a/32.png) [@phanikumar](https://discourse.chef.io/u/phanikumar)\
**Post date:** [March 16, 2016, 3:37pm UTC](https://discourse.chef.io/t/unable-to-attach-ebs-block-in-aws/7997/1 "2016-03-16T15:37:01Z")

</div>

I am getting argument error while attaching the ebs volume with instance bootstrapped for the first time with chef provisioning aws for the below snippet of code.

machine ‘Sample’ do  
add\_machine\_options :ssh\_username =\> ‘ec2-user’,  
:bootstrap\_options =\> {  
:instance\_type =\> ‘t2.micro’,  
:image\_id =\> “ami-2051294a”,  
:associate\_public\_ip\_address =\> true,  
block\_device\_mapping: [{  
device\_name: ‘/dev/sdb’,  
ebs: {  
volume\_size: 6, # 1 GB  
delete\_on\_termination: true  
}  
}]  
}  
end

**ArgumentError: unexpected value at params[:block\_device\_mapping]**

---

<div class="post-metadata">

**Author:** ![nukepuppy](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/nukepuppy/32/1342_2.png) [@nukepuppy](https://discourse.chef.io/u/nukepuppy)\
**Post date:** [March 25, 2016, 1:06pm UTC](https://discourse.chef.io/t/unable-to-attach-ebs-block-in-aws/7997/2 "2016-03-25T13:06:53Z")

</div>

I have probably 2 suggestions.

#### Solution to Problem

```auto
machine "ebstest" do
  chef_config "chef_server_url \"http://some-chef-server\""
  run_list ["role[some_role]"]
  chef_environment "mycloudenv"
    machine_options(
      lazy do
        {
          bootstrap_options: {
            subnet_id: "whatever"
            security_group_ids: ["group1", "group2"],
            key_name: "mykeyname",
            instance_type: "t2.micro",
            associate_public_ip_address: true,
            image_id: "ami-XXXXXXXX",
            block_device_mappings: [
              {
                device_name: "/dev/xvdf",
                ebs: {
                  volume_size: 15,
                  delete_on_termination: true,
                  volume_type: "gp2", # accepts standard, io1, gp2
                },
              },
            ],
        },
          convergence_options: {
            prerelease: "false",
            chef_client_timeout: 120*60, # Default: 2 hours
            ssl_verify_mode: :verify_none
      },
          ssh_username: "centos",
          aws_tags: {:tagitwith => "sometag" }
     }
    end # end of lazy
  ) # end of machine options for this instance
end

```

_My solution on handling this in a more graceful way - and honestly faster/more reliable_

Instead of trying to attach and do everything in one go… I’ll suggest approaching things in 3 phases…

#### :setup phase - build your machines/infrastructure (no actual converges) but you can register with chef servers… setup all the infrastructure etc… take advantage of machine\_batch for lots more speed… just remember to machine\_batch action :setup… you can also do loops and so on to create various boxes in this stage (in parallel)

```auto
machine_batch do
  action :setup
    machine "machine1" do
      ...
    end
end

```

#### intermediate stage. Do things like create and attach EBS volumes … attach machines you built to load balancers…

so here we can build an ebs volume and attach it to our previously created machine that just did :setup

```auto
aws_ebs_volume 'my-ebs-volume1' do  
  machine 'ebstest'  
  size 15  
  volume_type 'gp2'  
  device '/dev/xvdf'  
end

```

you can also do other things in this stage too like create ELBs… or anything really

#### Converge your nodes to apply software/automagic stuff etc… remember its ruby so you can do loops and other things etc to make your recipe more dynamic

```auto
machine_batch do
  action :converge_only
    machine "ebstest" do
    end
    machine "otherboxes" do
    end
end

```

I HIGHLY prefer the 2nd method… as its less clunky! and less prone to failure… just remember you have to clean up the volumes yourself if you’re doing tests (as in some kind of destroy recipe that enumerates all your resources)

Hope this helps!