From Fedora Project Wiki
Line 110: Line 110:


== Scope ==
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
=== Proposal owners ===
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
{{admon/warning|uh, help wanted, y'all}}
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook  -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


* Trademark approval: N/A (not needed for this Change)
=== Other developers ===
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
 
*  
 
 
=== Release engineering ===
 
The primary release engineering effort is the nightly production of images. The current release engineering tools have all the parts needed to do this, but have never been used in that way before, so some development effort is required to enable the production of current + updates nightlies. (This work, however, many also benefit other areas of the project, like updated Cloud Base images or even Workstation live CDs.)
 
Additionally, as described above, the tool to automatically ship auto-accepted images every two weeks logically falls under the rel-eng banner.
 
Adam Miller, on the release engineering team, is specifically prioritizing this work.
 
=== Other ===
 
* Policies and guidelines: none
 
* Trademark approval: ticket to be filed with the Council


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==

Revision as of 21:29, 16 June 2015

Two Week Atomic

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/


Owners

  • 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/

Naming and Trademark

We would like to use the name "Fedora Atomic Host", and phrasing like "Fedora Atomic Host, based on Fedora 22". This highlights the fact that while this project is under the Fedora umbrella, it isn't part of the traditional distribution release cycle. (The various images will be distinguished by date rather than by number.)

Fedora Atomic Host was previously presented as part of the general Fedora release under Fedora Cloud, but this new, separate approach should get council approval under the Trademark Guidelines for new combinations of unmodified Fedora software.

Marketing

The Cloud WG had previously considered making Fedora Atomic Host its main offering, however at present Atomic is not ready to fill that role, as it is changing too fast and not flexible enough for all use cases the Cloud WG targets. The Cloud WG / Cloud SIG will need to find other selling points. It may be that after several cycles, Atomic will mature enough to be the primary Fedora Cloud offering.

The two-week cycle means no big semi-annual PR blitz, but interesting new features and functionality should come rather frequently. This may provide an opportunity for showcasing Fedora in the middle of our development cycle, when Fedora usually doesn't get much press.

Benefit to Fedora

  • Fedora Atomic Host puts Fedora in the spotlight as a leader in modern operating system innovation
  • Fedora becomes the proper upstream for Atomic Host development
  • Early-adopters interested in collaborating on Atomic development have a public place to do so
  • Fedora users interested in Atomic get a better experience

Scope

Proposal owners

uh, help wanted, y'all


Other developers


Release engineering

The primary release engineering effort is the nightly production of images. The current release engineering tools have all the parts needed to do this, but have never been used in that way before, so some development effort is required to enable the production of current + updates nightlies. (This work, however, many also benefit other areas of the project, like updated Cloud Base images or even Workstation live CDs.)

Additionally, as described above, the tool to automatically ship auto-accepted images every two weeks logically falls under the rel-eng banner.

Adam Miller, on the release engineering team, is specifically prioritizing this work.

Other

  • Policies and guidelines: none
  • Trademark approval: ticket to be filed with the Council

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