Ubuntu Wiki

This page covers the naming convention for ec2 images published to ec2.

buckets names

The following buckets will be created in each region, with a suffix of '-<location>' to indicate region:

• ubuntu-images
• ubuntu-kernels
• ubuntu-images-testing
• ubuntu-kernels-testing

So, for example, there will be buckets named:

• ubuntu-images-us
• ubuntu-images-us-west-1
• ubuntu-images-eu
• ubuntu-images-testing-us
• ubuntu-images-testing-us-west-1
• ubuntu-images-testing-eu

I've also considered a bucket for alpha/beta/rc (maybe ubuntu-images-dev, ubuntu-kernels-dev). That would help to differentiate those both from daily builds and official releases.

Note, "location" mapps to region in the following way:

manifest names

images

Image manifest names are composed of the following parts delimited with '-'

• ubuntu [constant string]
• distro codename [one of jaunty, karmic, lucid ... ]
• version string [version number, 'alpha', 'beta', 'daily' ]
• architecture indicator [i386 or x86_64]
• date indicator in YYYYMMDD format
• optionally a serial for YYYYMMDD [.1, .2 , ...]

The following are example image manifest names

• ubuntu-karmic-9.10-i386-server-20090930
• ubuntu-karmic-alpha-i386-server-20090930
• ubuntu-karmic-9.10-beta-x86_64-server-20091003
• ubuntu-karmic-daily-x86_64-server-20091005.1

Note, beta and beyond receive the numerical version number in their filename. This is consistent with other ubuntu releases.

kernels / initramfs

Kernel initrd and kernels names will be composed of the following parts:

• ubuntu [constant string]
• distro codename [one of jaunty, karmic, lucid ... ]
• architecture indicator [i386 or x86_64]
• package name string [linux-image-ec2]
• version delimiter [constant '-v-']
• version string [example: 2.6.31-300.5]
• content description ["ramdisk" or "kernel"]
• serial
  • for ramdisk, this will be the serial of the build in which it was created. Ie, 20091020. This mapping of root filesystem to ramdisk is necessary because the ramdisk contains portions of the rootfilesytem from which it was created. Rather than worry about figuring out when the ramdisk would need to be changed, we will simply pair rootfs and ramdisk.
  • for kernel, this should not be needed, but if so, it would be '.1'

The following are examples:

• ubuntu-karmic-i386-linux-image-2.6.31-300-ec2-v-2.6.31-300.5-kernel.img
• ubuntu-karmic-i386-linux-image-2.6.31-300-ec2-v-2.6.31-300.5-ramdisk.20091020.img
• ubuntu-karmic-x86_64-linux-image-2.6.31-300-ec2-v-2.6.31-300.5-ramdisk.20091020.1.img
• ubuntu-karmic-x86_64-linux-image-2.6.31-300-ec2-v-2.6.31-300.5-kernel.img

The above allows for programatically extracting package name and version in order to obtain the correct source package. This can be done by taking of the first 3 tokens and last token of '-' delimited string (ie, remove 'ubuntu-karmic-i386-' and '-kernel.img'), and then splitting on '-v-'. This results in package=linux-image-2.6.31-300-ec2 and version=2.6.31-300.5. It does require that the serial (.1) does not include a '-').

Notes:

• In karmic

  • linux-ec2 is a meta package that depends on a specific version of linux-image-ec2.

  • linux-image-ec2 is itself a meta package that depends on linux-image-2.6.31-300-ec2.

  • linux-image-2.6.31-300-ec2 has a version of (currently) 2.6.31-300.5 . There should only be one version of this package at any time in the archive. It actually contains the linux binary, and installation of it creates the ramdisk.

  • given the above, the most complete name would need to include linux-image-2.6.31-300-ec2 and 2.6.31-300.5

The following are existing examples:

• karmic-kernel-zul/ubuntu-kernel-2.6.31-300-ec2-i386-20091002-test-04.manifest.xml
• canonical-cloud-us/ubuntu-kernel-2.6.31-300.3-ec2-x86_64.manifest.xml

Promoting Methodology

Candidates for alpha/beta/rc will be taken from daily builds. Their ami ids will be published to the ISO tracker, and testing will be done. Successful candidates will be then moved to their final resting place, and renamed with the proper version string (ie, change 'daily' to 'alpha5'). This will create a new AMI id.

The daily build will be left for removal in the normal course according to removal policy.

removal policy

testing build removal

Builds will be removed on a rolling basis from 'testing' buckets. The latest 5 builds will be kept as public images. A daily job will crawl through public 'testing' images and remove public access from old testing.

This daily job will place a marker file in s3 along side of the manifest file for the ami/aki/ari. The marker file will contain the date that public access was removed.

Another job (run less frequently) will crawl through builds that do not have public access and remove those that have been private for 30 days or more.

milestones / release removal

Milestones (alpha, beta, rc) and official releases will never be removed.

Other Notes

• Migration: ec2-migrate-image makes reference to a 'mapping'. It seems to indicate that the tool will look somewhere in s3 for a file that links a kernel or initrd in US location to one in the eu location, and automatically use that if the user migrates an image. This would be "nice to have" for ubuntu's use, but would be nicer for users who rebundled images. We should look into maintaining the mapping file so that a user can migrate an image with this tool and have kernel/initrd migrate seamlessly. I posted a question on aws forums asking for some info. There is source available for ec2-migrate-bundle and ec2-migrate-manifest, so this could at least be reverse engineered.

• ec2-version-query : It might make sense to implement ec2-version-query in s3 buckets. This could be written to from the nectarine builds/publishing with the already present credentials. The only negative I can think about this is that it is intimately tied to ec2. This might be less desirable than a more generic site if ever ubuntu is to produce other cloud images (non-ec2)
• sandbox buckets : in the past, we've had "sandbox" builds published under the 'canonical' id. This is actually valid for kernel and initramdisk as only the canonical user can publish a kernel/initramdisk (this right isn't given to all AWS ids). I'd like to have a bucket and naming convention that clearly distinguishes "sandbox" builds from official.

Buckets

The canonical account now owns the following buckets:

ubuntu-images-us
ubuntu-images-eu
ubuntu-images-testing-us
ubuntu-images-testing-eu
ubuntu-images-sandbox-us
ubuntu-images-sandbox-eu
ubuntu-images-milestone-us
ubuntu-images-milestone-eu
ubuntu-kernels-us
ubuntu-kernels-eu
ubuntu-kernels-testing-us
ubuntu-kernels-testing-eu
ubuntu-kernels-sandbox-us
ubuntu-kernels-sandbox-eu
ubuntu-kernels-milestone-us
ubuntu-kernels-milestone-eu

Additionally, I've created the following buckets with the account, primarily to reserve them:

ubuntu-data
ubuntu-us
ubuntu-eu
ubuntu-testing-us
ubuntu-testing-eu
ubuntu-sandbox-us
ubuntu-sandbox-eu
ubuntu-milestone-us
ubuntu-milestone-eu

the 'ubuntu-data' bucket may be used for storing information about our images (such as a mapping file).