EC2AutomationSpec

Differences between revisions 1 and 10 (spanning 9 versions)
Revision 1 as of 2009-06-02 14:56:49
Size: 2001
Editor: 0107ds1-abv
Comment: Not done yet..
Revision 10 as of 2009-11-10 14:32:16
Size: 3837
Editor: d14-69-66-169
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Describe EC2AutomationSpec here.##(see the SpecSpec for an explanation) ##(see the SpecSpec for an explanation)
Line 3: Line 3:
 * '''Launchpad Entry''': UbuntuSpec:server-karmic-ec2-automation  * '''Launchpad Entry''': UbuntuSpec:server-karmic-ec2-release-process
Line 5: Line 5:
 * '''Contributors''': SorenHansen
 * '''Packages affected''':
 * '''Contributors''': SorenHansen , ScottMoser
 * '''Packages affected''': vmbuilder
Line 10: Line 10:
This spec defines the automation process of the building of the EC2 images. The current process involves some error prone manual steps. We want the EC2 image building process to follow that of every other image build in Ubuntu, so we want daily, automated builds, and a very well described process for publishing these to EC2. This spec describes the automation of the process of building the Ubuntu EC2 images. The current process involves some error prone manual steps.

We want the EC2 image building process to follow that of every other image build in Ubuntu, so we want daily, automated builds, and a very well described process for publishing these to EC2.
Line 18: Line 20:
The current process is error prone as it's manual and not very well defined. This makes us look bad and needs to be fixed ASAP. The current process is error prone as it's entirely manual and not very well defined. This makes us look bad and needs to be fixed ASAP.
Line 22: Line 24:
1. Dennis hears that Ubuntu Karmic alpha-3 is out and wants to test it on EC2.
1. Edward wants to test Ubuntu Karmic beta on his own cloud.

== Assumptions ==
 1. Dennis hears that Ubuntu Karmic alpha-3 is out and wants to test it on EC2.
 1. Edward wants to test Ubuntu Karmic beta on his own cloud.
Line 29: Line 29:
Building the filesystem images should be completely automatic. The build should result in a set of filesystem images. These are useful for local testing (in either straight KVM or in UEC). The release process, which is (and should be) manual, should be extremely well defined (like a recipe with clearly phrased, discrete steps to be taken from the availability of the image until people can start using them on EC2). Building the filesystem images should be completely automatic.

The build should result in a set of filesystem images available alongside the ISO's on cdimage.ubuntu.com (or in a similar location). These are useful for local testing (in either straight KVM or in UEC) and for use with private clouds. The release process, which is (and should be) manual, should be extremely well defined (like a recipe with clearly phrased, discrete steps to be taken from the availability of the image until people can start using them on EC2).

Also, the release team should include announcements of the availability of the EC2 images in their regular announcements of Alpha, Beta, RC and final releases.
Line 33: Line 37:
There are three major parts to this project:
 * Get access to build ressources in the DC.
 * Merge VMBuilder-EC2 with VMBuilder proper.
 * Define the recipe for publishing releases.
 1. Get access to build ressources in the DC.
  * DONE
 1. Merge VMBuilder-EC2 with VMBuilder proper.
  * DONE
 1. Once 1 and 2 are done, a cron job needs to be setup to build the various images every day and publish them somewhere.
  * DONE
 1. Define the recipe for publishing releases.
  * Depends on the specifics of the implementation of UbuntuSpec:server-karmic-ec2-kernel, but should in any case be modeled after ReleaseProcess.
Line 42: Line 50:
== Final Notes ==
Our [[http://uec-images.ubuntu.com/releases/|UEC Images]] for karmic RC and Release were built and published using fully automated builds. The process will continue for Lucid, and has been put into place for Hardy also (note, hardy kernels still require manual effort).

The following are links are relevant (current at 2009-11-10):
  * [[https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds|automated-ec2-builds]]: This is the highest level scripts, those that are directly called from cron on our build machine. Additionally, the crontab for the 'vmbuilder' on that machine is stored here.
  * [[https://code.edge.launchpad.net/~ubuntu-on-ec2/ubuntu-on-ec2/ec2-publishing-scripts|ec2-publishing-scripts]]: These scripts are utilized for publishing of ec2 content. Many of them are actually generally useful outside of this scope. For example, see 'publish-image' that can publish an image, kernel, or ramdisk to ec2 including migrating it to multiple regions.
  * [[UEC/Images/Publishing]]: This covers "how to publish" a released build. Note, the process is actually a "republish" of an already existing nightly.
  * [[UEC/Images/NamingConvention]]: This covers the naming convention for our builds. Consistent naming and well named buckets allow.

Summary

This spec describes the automation of the process of building the Ubuntu EC2 images. The current process involves some error prone manual steps.

We want the EC2 image building process to follow that of every other image build in Ubuntu, so we want daily, automated builds, and a very well described process for publishing these to EC2.

Release Note

Ubuntu on EC2 now follows the same release schedule as the rest of Ubuntu.

Rationale

The current process is error prone as it's entirely manual and not very well defined. This makes us look bad and needs to be fixed ASAP.

User stories

  1. Dennis hears that Ubuntu Karmic alpha-3 is out and wants to test it on EC2.
  2. Edward wants to test Ubuntu Karmic beta on his own cloud.

Design

Building the filesystem images should be completely automatic.

The build should result in a set of filesystem images available alongside the ISO's on cdimage.ubuntu.com (or in a similar location). These are useful for local testing (in either straight KVM or in UEC) and for use with private clouds. The release process, which is (and should be) manual, should be extremely well defined (like a recipe with clearly phrased, discrete steps to be taken from the availability of the image until people can start using them on EC2).

Also, the release team should include announcements of the availability of the EC2 images in their regular announcements of Alpha, Beta, RC and final releases.

Implementation

  1. Get access to build ressources in the DC.
    • DONE
  2. Merge VMBuilder-EC2 with VMBuilder proper.
    • DONE
  3. Once 1 and 2 are done, a cron job needs to be setup to build the various images every day and publish them somewhere.
    • DONE
  4. Define the recipe for publishing releases.

Test/Demo Plan

The Jaunty EC2 release will be the guinea pig (this sounds much worse than it is.. This is a new process, but should in every way be superior to the previous, manual approach). We'll shortly release a beta of the Jaunty images built in the DC and released according to the recipe.

Final Notes

Our UEC Images for karmic RC and Release were built and published using fully automated builds. The process will continue for Lucid, and has been put into place for Hardy also (note, hardy kernels still require manual effort).

The following are links are relevant (current at 2009-11-10):

  • automated-ec2-builds: This is the highest level scripts, those that are directly called from cron on our build machine. Additionally, the crontab for the 'vmbuilder' on that machine is stored here.

  • ec2-publishing-scripts: These scripts are utilized for publishing of ec2 content. Many of them are actually generally useful outside of this scope. For example, see 'publish-image' that can publish an image, kernel, or ramdisk to ec2 including migrating it to multiple regions.

  • UEC/Images/Publishing: This covers "how to publish" a released build. Note, the process is actually a "republish" of an already existing nightly.

  • UEC/Images/NamingConvention: This covers the naming convention for our builds. Consistent naming and well named buckets allow.


CategorySpec

EC2AutomationSpec (last edited 2009-11-10 14:32:16 by d14-69-66-169)