[ubuntu-cloud] RFC: EC2 / UEC Image updates

[Joe Williams]

Scott,

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.

-Joe



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
> Cloud.
> 
> 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 [1]
> and corresponding with release milestones [2] 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
> release.
> 
> == 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
> time.
> 
> = 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
> ec2-init)
> 
> 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 [3] is currently being discussed.
> 
> Some discussion is happening on bug 423856 [4] 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).
> 
> --
> [1] http://uec-images.ubuntu.com/releases/karmic/alpha-4/
> [2] http://uec-images.ubuntu.com/releases/karmic/
> [3] http://people.canonical.com/~soren/ec2-version-query/
> [4] https://bugs.launchpad.net/bugs/423856
> 


-- 
Name: Joseph A. Williams
Email: joe at joetify.com
Blog: http://www.joeandmotorboat.com/