[ubuntu-cloud] RFC: EC2 / UEC Image updates
joe at joetify.com
Thu Sep 10 20:00:14 BST 2009
I think this all sounds pretty good. I think the sticking points are
when to update AMIs and notification of updated AMI's. You are on the
right track regarding creating a metric for which updates are needed.
Total update time seems like a reasonable one to me, or perhaps some
sort of combined metric of total package size, total update time and
the number of packages updated. Keeping updates fast but not creating a
new AMI for each update is the balance here I suppose.
Regarding notifications of updates, having a notification in the MOTD at
boot would be pretty nice as mentioned in the bug ticket. The downsides
that Eric Hammond mentioned are also legitimate. Personally for me
checking http://alestic.com/ every few weeks does the trick but some
sort of notification would be deluxe.
On Thu, 10 Sep 2009 13:04:57 -0400 (EDT)
Scott Moser <smoser at ubuntu.com> wrote:
> For some time, the ubuntu server team has been producing
> ubuntu-server images to run on Amazon's ec2. Additionally, these
> images can be run un-modified as an instance in a Ubuntu Enterprise
> I've been working on putting together a release policy for ec2 and
> uec images that will cover both stable and development releases.
> I've put that work at
> https://wiki.ubuntu.com/UEC/Images/RefreshPolicy . The following is a
> copy and paste with quick re-format for email to make reading /
> responding easier.
> Please take a read if you have any suggestions for improvements or
> clarification, let me know.
> = Overview =
> This page covers the policy for releasing updated Ubuntu images to
> EC2. It is a work in progress and nothing is set in stone.
> Currently, EC2 and UEC Images are being built nightly 
> and corresponding with release milestones  for karmic. Updates to
> stable releases have been infrequent and were not covered by any
> policy or process.
> = Background Information =
> The following are things to consider:
> * As updates are made available to a development or stable release,
> the time it takes for an instance of that image to update itself
> increases. This is different than other releases. Each new
> instance is essentially a fresh media based install, and needs
> appropriate updates.
> * There is no way to change the default kernel (aki) and ramdisk
> (ari) associated with a AMI. Instead, you have to publish a new
> AMI each time a new kernel or ramdisk is available.
> * When starting an instance, the user ''can'' choose a different
> kernel and ramdisk than the default associated with the ami.
> * The kernel modules are stored on the AMI and must exactly match the
> kernel release name (e.g., "2.6.28-15-server"). If the updated AKI
> has an upgraded release, then the kernel modules on the AMI won't
> be useful with the new kernel.
> * There may occasionally be enhancements in Amazon's EC2 environment
> which would require changes to the ec2-init startup code so users
> can take advantage of them.
> = Kernel Updates =
> == Stable Releases ==
> EC2 kernels and ramdisks will be released when kernel updates are
> done. For example, each time a new version of linux-image is
> released, a new aki and ami will be released.
> With the release of a new AKI and ARI, a new AMI will be released.
> The released AMI will include in it the new AKI and ARI as default
> kernel/ramdisk. It will also include any updates released since the
> previous AMI release. This will help alleviate possible release churn
> that might occur if need to refresh a AMI came soon after kernel
> == Development Releases ==
> Kernels and ramdisks for development releases will be released when
> the corresponding AMIs are released.
> For development releases there will not be separate AMI and AKI/ARI
> releases. An AMI will be released with the latest kernel at that
> = AMI Updates =
> == Stable Releases ==
> New AMIs will be published for stable releases based on
> a. The time it takes for an 'apt-get dist-upgrade' to occur on
> latest AMI for a given release. Experimentation will need to be done
> to determine how best to monitor this. The initial suggestion is to
> use the combined size of updates needed and refresh when that goes
> over a certain value. Also being considered is ac tually monitoring
> the time on an ec2 instance.
> b. Security updates or major flaws. If there are highly important
> security updates or major functionality fixes available that
> cannot be obtained via 'apt-get update', then new AMIs may be
> released to incorporate those changes outside of 'a' above. Such an
> example would be changes to software that runs on first boot (such as
> At the time of publish, AMIs will be associated with the latest
> AKI/ARI that is available.
> == Development Releases ==
> Development releases will regularly update the AMIs. Each AMI
> published will reference the latest AKI/ARI available at the time.
> = Currency =
> We will need to provide an easy way for a user of Ubuntu EC2 images to
> find out what the most current version of their AMI is. For example,
> if the user is running 'ami-123456' that is hardy-i386, they will be
> interested to know if there are updates for that (aki,ari, or ami).
> The directory tree at  is currently being discussed.
> Some discussion is happening on bug 423856  regarding ami images
> checking for updates themselves.
> = Support Life Time =
> The release policy above will apply to EC2 images for the same time
> frame that is applied to other Ubuntu Server releases. That is 5
> years for LTS releases, and 18 months for other releases.
> This will apply to Karmic (9.10) and following releases.
> Additionally, it will apply to Hardy (8.04).
>  http://uec-images.ubuntu.com/releases/karmic/alpha-4/
>  http://uec-images.ubuntu.com/releases/karmic/
>  http://people.canonical.com/~soren/ec2-version-query/
>  https://bugs.launchpad.net/bugs/423856
Name: Joseph A. Williams
Email: joe at joetify.com
More information about the Ubuntu-cloud