Features/FirstClassCloudImages

First-Class Cloud Images

Summary

This feature expands Fedora's current cloud image deliverables beyond just EC2, and overhauls how they are produced. A goal is to produce cloud images for EC2 and other cloud deployments for the Alpha, Beta, and Final compose process and distribute them on the mirror network. There will also be nightly or weekly image builds for Rawhide to assist with early development. All images should be constructed using a newer generation of tools.

Owner

• Name: Matthew Miller
• Email: mattdm at fedoraproject dot org

Current status

• Targeted release: Fedora 19
• Last updated: January 20, 2013
• Percentage of completion: 0%

Detailed Description

• New images that can be used in other cloud deployments (such as OpenStack, CloudStack, or Eucalyptus) will be produced. They will be in a qcow2 format and lack the EC2-specific customization. Images for this feature would ideally work for all cloud deployments and there will be i686 and x86_64 versions of both image types. In total and "image drop" will have 4 images: 2 arches for 2 different types (EC2, not-EC2).
• An image drop will be produced for Alpha, Beta, and Final composes for Fedora 19 and forward.
• Scratch build image drops will be produced on a weekly basis for Fedora 19.
• Scratch build image drops will be produced on a weekly basis for Rawhide as well to enable early testing.
• The Fedora Koji instance needs to be updated to a future release that will integrate with ImageFactory and Oz from the Aeolus Project. This future release is not implemented yet.
• The EC2 images will be automatically uploaded and registered in EC2. The Final AMIs for Fedora 19 will be available in the Amazon marketplace.

Benefit to Fedora

• Cloud images more easily available to users
• Cloud images available for better testing
• Continuous building of images provides new opportunities for early platform testing
• appliance tools, which is the workhorse for image building today, does not have an upstream. ImageFactory does.
• appliance-tools uses chroots which suffer from build-time complications like kernel mismatches. Moving off of this tool will unburden Rel-Eng with that work.

Scope

ImageFactory/Oz Integration with Koji

Creating LiveCDs with the same system will also require some changes to ImageFactory/Oz. These will use existing technology in livemedia-creator (not to be confused with livecd-creator). If possible, the image building process will be executed within a chroot to reduce the support burden on Rel-Eng and follow the design spirit of Koji. If this is not possible in the time alotted, ImageFactory/Oz will need to be installed on the build hosts, and kojid will make use of them when it takes an image building task. (this has an increased support burden on Rel-Eng.

Build System Update Deployment

This feature requires a significant change to Koji that will need to be deployed to the production build system. ImageFactory/Oz builds the images inside a small VM, and because a nested virt scenario is not possible on RHEL 6 (which is what the builders are) it will require bare metal builders to be available.

There are 2 bare-metal builders available today to accommodate this requirement. (thank you Dennis Gilmore)

Process and Infrastructure Updates

Release Engineering will produce image drops on a weekly basis and for milestone updates. These will need to be easily discoverable so that announcements and communication about their release is easily consumed. (from the Cloud SIG web page, for example). Procedures for producing, testing, and blessing the images should be documented and communicated as well.

Milestone image drops will be released using the current Fedora mirroring system, alongside the install images.

Milestones

Approximate dates to be added shortly.

• Out-of-Koji test implementation
• Code landed in Koji
• Builders updated
• Test-builds are functional
• Scripting for automatic weeklies
• Weeklies hitting alt
• Actual builds for alpha, beta, final on the mirrors

How To Test

• Do the images exist?
  • In EC2
  • Weekly in wherever those will go
  • On the mirrors for Alpha, Beta, and Final
    • in qcow2
    • in raw.tar.xz
• Do the downloadable images boot in
  • OpenStack?
  • Eucalyptus?
• Installed image should appear similar to one installed by Anaconda

User Experience

Official cloud images downloadable from mirror system.

Dependencies

None outside those identified in the scope.

Contingency Plan

Livemedia-creator could be used instead of Oz.

Failing that, continue to use appliance-creator for EC2 images and to generate images for download outside of official channels. Feel sad.

If the Koji integration work is not completed before Fedora 19 Alpha, consider updating Fedora Koji to the 1.7.1 release, which tracks images using the same data model as RPMs. This will at least improve the manageability if the images produced.

Documentation

See Features/FirstClassCloudImages/Whiteboard

Possibly a small readme file should go alongside the images. Primary documentation on Cloud SIG web page.

Release Notes

TBD

Comments and Discussion

• See Talk:Features/FirstClassCloudImages