Apache brooklyn create own volumes instead of using the existing one

I use Apache Brooklyn 0.8.0-incubating to create d2.xlarge instance on AWS with the following Blueprint:

location: 
 jclouds:aws-ec2:
   region: eu-central-1
... 
provisioning.properties:
  imageId: eu-central-1/ami-7bcddf17 # Redhat 6.6
  hardwareId: d2.xlarge # with 2TB EBS

On the machine are only 10GB total storage. After some research I found the instance volume under /dev/xvdb unpartioned.

Can me anybody explain how I can use instance storage instead of creating a new volume for the machine on AWS?

Best Regards, Felix

Solution

This is the expected behaviour for VMs in AWS EC2.

As described in http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/add-instance-store-volumes.html:

"After you launch the instance, you must ensure that the instance
store volumes for your instance are formatted and mounted before you can use them. Note that the root
volume of an instance store-backed instance is mounted automatically."

"the instance type determines which instance store volumes are mounted for you and which are available for you to mount yourself"

For your instance type, it looks like the instance store volume is attached unformatted.

The EC2 docs talk about running lsblk, mkfs and mount to format and mount the instance store volume.

Expected behaviour also depends on the AMI: "Each AMI has a block device mapping that specifies the block devices to attach to an instance when it is launched from the AMI. An AMI that Amazon provides includes a root device only."

Note that what you get working on one AMI might not work on all other AMIs (e.g. because of different block device mappings). Sticking with Amazon's own AMIs is often a good idea, for getting sensible default behaviour.

This could be automated in Apache Brooklyn. You have a few options for that:

Implement it in the entity, e.g. if using a SoftwareProcess entity then you could use the config key pre.install.command to execute the bash commands to set up the volume.
Implement it in the location.
- This could use a new MachineLocationCustomizer to execute the commands on the machine (and then configure that on the location).
- Alternatively, for jclouds locations you could use the setup.script configuration, which takes the URL of a shell script to execute.

Of those approaches, the MachineLocationCustomizer gives you the most power and flexibility.