From Fedora Project Wiki

Two Week Atomic

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Summary

Fedora Atomic Host is an implementation of the Project Atomic pattern for a specialized operating system for the deployment of containerized applications. For the past two Fedora releases, we've included an Atomic Host cloud image as a non-blocking deliverable. However, upstream Atomic is moving very fast — by the end of the alpha, beta, final stabilization cycle Fedora uses, the released artifact is basically obsolete. Additionally, the Project Atomic team at Red Hat would like to do their ongoing development work in the Fedora upstream, and the six-month release cycle does not lend itself to that.


This change moves Atomic away from the main Fedora 6-month distribution release, and instead to separate releases every two weeks on a new web site, http://atomic.fedoraproject.org/


Owner

  • Name: Matthew Miller
  • Email: mattdm@fedoraproject.org
  • cosigners wanted!
  • Release notes owner:

Current status

  • Targeted release: Fedora 23 (but actually ideally will start with F22, long before F23 release)
  • Last updated: 2015-06-16
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Delivery

1. Move Atomic away from the main Fedora 6-month distribution release, including:

2. Updated Fedora Atomic Host images produced every two weeks, and presented at:

Image Production

1. Images will be produced nightly (See Release Engineering Ticket #6196.)

  • qcow2 / raw.xz
  • vagrant variant

2. These images will be built using Anaconda's ostree-target mode from a nightly tree built from the current Fedora release (i.e., currently Fedora 22) plus updates — this may include updates-testing.

  • will use current-release anaconda for this
  • may need a mechanism to include an updates.img

3. When the next Fedora release (e.g., F23) branches, those images will also start production (but may not be the target for release; see below)

Testing

  • Testing will be almost entirely automated and will not require extra resources from the QA team.
  1. Whenever a new image is produced, a listener will receive the associated message on the Fedora message bus
  2. a battery of tests will be automatically executed (initially using tunir (the goal is to migrate to Tasktron when that is ready)
  3. test results will be fed back to fedmsg
  4. and available on a dashboard somewhere
  • If no image is successfully produced, a tracker bug should be automatically filed
    • if an open tracker bug already exists, just add a comment rather than filing a new one
    • if such a tracker bug is open, a successful build should auto-close it
  • Of course, QA team expertise and help is always welcome
  • There should also be a mechanism for manually marking an image as failed even if it passes the automatic tests

Release

  • As with testing, the goal is for this process to be entirely automatic (after initial development, of course).

1. Every two weeks, a process will scan the fedmsg history for image builds which have passed the tests, and

2. If no image passed the tests since the previous image was posted:

  • leave link to previous image
  • include warning text that this is stale
  • link to most recent failure-tracking bug (see above)
  • decision! either:
    • a. rerun nightly until a successful image is found
    • b. just skip this cycle, to keep releases predicable

Docs and Website

The http://atomic.fedoraproject.org/ website will need initial design and creation, of course, but after that it is intended to be automated; no one should have to update links automatically. It should be a very simple design, with pointers to Fedora docs (hopefully, soon, new short-easy-docs website) and to http://projectatomic.io/

Marketing

  • Impact on Cloud

Benefit to Fedora

Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes