Upcoming EBS and S3 AMI changes

In light of some discussions we've been having internally, and with various community members, it has been proposed that as of our next BoxGrinder release, we shall no longer build images with ephemeral devices[1] pre-attached (for EBS), or pre-mounted in any fashion[2] by default (for EBS or S3)[3].

Instead we will emit a message at build-time about device attachment and mounting, advising users to install a script such as cloud-init to auto-mount ephemeral devices, as well as a pointer to a boxgrinder.org resource page explaining how best to bake in an appropriate cloud configuration file (more on that soon).

Those that want device mappings baked into their image will continue to be able to do so by defining their desired mappings via configuration. Note that block storage mappings (including ephemeral, or otherwise), can be configured or reconfigured at runtime instead of, or in addition to, build time.

Providing block device mappings

For EBS AMIs no ephemeral devices are attached by default, whereas with S3 AMIs there is a default layout (although you can modify it as you see fit).

At run-time

All of the standard methods of providing (or modifying) a block device mapping at run-time still apply. For example:

ec2-run-instances ami-12345678 -b /dev/xvdb=ephemeral0

At build time

You can speculatively map devices that may not be present in every instance size at build time.

# -d ami or -d ebs
boxgrinder-build my.appl -p ec2 -d ebs --delivery-config \ 
  block_device_mapping:'/dev/xvdb=ephemeral0&/dev/xvdc=ephemeral1'

Why the changes?

The reasons for this change are multitudinous, but the foremost are:

  • Ephemeral device mappings vary according to instance size: We cannot make any easy assumptions about which ephemeral disks will be present, as it varies depending on which instance size is selected, and is subject to arbitrary change by Amazon. For instance, recent problems with BoxGrinder S3 AMIs on m1.small instances were caused by BoxGrinder assuming a particular ephemeral device would be present; an assumption that fell over when AWS introduced a new device mapping layout[4].

  • We do not want to maintain a script that maps and mounts which devices are provided by which instance sizes, as it will duplicate existing well-established efforts (e.g. cloud-init), in addition to being difficult to maintain, inferior in functionality, and surprising to the user.

  • Confusion: Ephemeral device mappings do not show on Amazon API queries, or their web UI (!!). Users do not realise a device is attached until they attempt to attach their own device at the same location (e.g. /dev/xvdb is an ephemeral device mapping, but it does not show in the web UI; if the user attempts to attach a device at xvdb it will fail).

  • Inconsistency: BoxGrinder can build a few different OSes, and some of the best cloud initialisation projects are not necessarily available on all of the OSes default repositories. We would rather not force disparate solutions onto our users, as consistency is one of our primary goals.

Therefore we concluded that rather than a prescriptive or inconsistent solution, we shall provide extremely simple default behaviour, and enable the user to choose an approach that is optimal for them.

Thoughts?

If you have any objections, comments or suggestions, leave them in the comments, or send them to via any of our community channels.


[1] Ephemeral disks are transient/instance storage devices that are available 'free' with most instance sizes. The overall capacity included, and the number of devices the space is subdivided into varies by instance size. For example, a m1.large instance has 2x420GiB instance storage.

[2] There is an important distinction between attaching and mounting devices on AWS. Attaching is akin to physically plugging a disk into a machine. Mounting is the usual process of making a device available to the machine's file system.

[3] For the sake of clarity, it is worth noting that S3 Backed AMIs always have a pre-defined set of ephemeral device mappings provided by EC2, but with EBS by default there are none.

[4] In this particular case we were expecting /dev/xvdb to exist, but for m1.small the ephemeral device we wanted was mapped to /dev/xvda2.

BoxGrinder Build 0.6.5 released!

This is mostly a bugfix release including one very important bug. 32 bit AMIs produced by Fedora Cloud SIG showed up a nasty issue described in details in Red Hat Bugzilla bug report. After great help from Jeff Darcy - we have now a workaround. This workaround is now implemented in BoxGrinder. So, if you want to build Fedora 14 AMI's - please update BoxGrinder to the latest version!

Beginning with this version - BoxGrinder will not install ec2-ami-tools package by default for appliances converted to EC2 format. If you want still this package to be included in your AMI you need to do this manually. There are two steps to do this:

  1. Put this package to a local repository and add it to packages section.
  2. Install the package using post section:

        post:
          ec2:
            - "rpm -Uvh http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm"
    

Release Notes

Bug

  • [BGBUILD-105] - No plugin-manager require for local delivery plugin
  • [BGBUILD-106] - No plugin-manager require for fedora os plugin
  • [BGBUILD-107] - No plugin-manager require for vmware platform plugin
  • [BGBUILD-108] - No plugin-manager require for sftp delivery plugin
  • [BGBUILD-109] - readdir64 bugfix for i386 base AMIs

Task

  • [BGBUILD-111] - Don't install ec2-ami-tools by default in AMIs

EBS AMI support for BoxGrinder

There is one issue in BoxGrinder JIRA we have been asked since long time. This is BGBUILD-3: support for EBS-type AMI's. Yesterday I commited initial support for this. What does it mean for you? Simple – you can now build appliances using BoxGrinder and then deliver them as EBS AMI's to Amazon Web Services.

It's here!

This was implemented as a new delivery plugin. Be aware that currently only Fedora 13 is supported – we'll expand support for other platform in the near future.

The plugin is not yet released, it'll be released along with BoxGrinder Build 0.6.0 in the next weeks. If you want try it now – please download nightly artifacts from our CI. Make sure you install also new version of boxgrinder-core and boxgrinder-build (also from CI) because the EBS plugin forced to make some changes in the core. To do this please download all required gems, put them in a directory and install them using this command:

gem install *.gem

How to use it?

It's just another delivery plugin. The only thing which is different is that you must execute the build on an EC2 instance. This is really important. The reason is because we need to mount an EBS volume to the instance and we can do this only on EC2. But don't be afraid – we have meta appliance you can run on EC2 and use it to build your appliances.

boxgrinder-build you_definition.appl -p ec2 -d ebs    

Of course make sure you created valid configuration file for this plugin as described here before you start.

I need help!

If you find bugs in that plugin, please report them in our issue tracker. You can always ask us for help on our forums or on ournew IRC channel: #boxgrinder@ freenode.net.