From Fedora Project Wiki

Document Purpose and Overview

This is the Product Requirements Document for the Fedora Atomic Working Group. It:

  • Provides a high-level market of the cloud computing market as it pertains to Fedora Atomic; this includes overviews of things which may not be within our actual scope/ability to accomplish at the current time.
  • Provides deeper understanding of the types of users who could use Fedora for their application deployment needs. This includes describing their main day-to-day tasks, common problems, and so on. The perspective here is not necessarily limited to system administrators, or developers, but a combination of many types of users and roles.
  • Ties common issues and needs of potential users and consumers of the Fedora Atomic product to high-level product needs, from a "functional" standpoint
  • Provides solutions, in the form of "changes" or "features" which will provide the functionality described as needs for the potential users.

Release/Product Overview

Fedora Atomic provides a lightweight, immutable platform, designed with the sole purpose of deploying and scaling containerized applications on public and private clouds, as well as on virtual and physical infrastructure.

Market Opportunity

The market around Linux containers and "microservices" architecture is growing rapidly, as are the technologies and processes that enable it.

From public and private clouds to traditional virtualization systems and bare metal environments, there's an opportunity for Fedora to unseat incumbent distributions and strengthen its overall adoption by better serving these new application deployment models.

Fedora, being a leading-edge Linux distribution, is the ideal place to collaborate on fast-moving components such as the Linux kernel, the docker runtime and the kubernetes orchestration system, particularly when combined with image-based system updates via rpm-ostree.

Longer term, the technologies included in Fedora Atomic for enabling atomic system updates and containerized application hosting will have relevance to other Fedora products, there's an opportunity for this work group to help develop and spread these technologies to other parts of the Fedora community.

Product Objectives

The primary deliverable of the WG is the Fedora Atomic Host, a lightweight container OS image composed from standard Fedora rpms using rpm-ostree. Initially, the Atomic Host is focused on the docker runtime and on kubernetes orchestration, but will allow for the use of other runtimes and orchestration technologies.

Fedora Atomic Host can be used at various scales. For example, it could be used in the following example environments:

  • Running as a VM on a developer workstation.
  • Running on bare metal or virtual machines in a data center.
  • Running as a cloud image on a public or private Infrastructure-as-a-Service (IaaS) cloud.
  • Running as the embedded OS in an IoT device

Secondary Objectives

1. Production, promotion, and distribution of Fedora-based container images. Initially this is via the Fedora Docker Layered Image Build Service. This includes:

   * encouraging production of a broad and diverse library of container images
   * qualifying images and ensuring that guidelines for quality images are followed
   * promoting Fedora-based images to application developers and operators

2. Development, maintenance and distribution of a Fedora-based full-stack container cluster environment

   * based on OpenShift Origin
   * includes work on development of installation and deployment tools for easy user start-up

Target Market / Audience

Developers and operators creating containerized workloads, and organizations and users running those applications. Fedora is particularly interested in organizations that might want to contribute back to Fedora and be involved in helping find/report/fix bugs, and develop new features. Organizations with a strong interest in an immutable OS even without containers, such as "Internet of Things" system builders.

Delivery Mechanisms

Atomic Host images must be easy to consume as part of a public or private cloud, as virtual machines, or on bare metal. Because we target these environments, we'll produce ISO images, downloadable VM or cloud images, and vagrant images, as well as work to make Atomic Host images available within popular public cloud services.

Where to obtain

Users will be able to obtain the images for public clouds via download or via the usual marketplace for those images. For instance, we publish AMIs directly to AWS. Users are able to launch new instances with Fedora without having to obtain the images directly from the Fedora Project and then upload to AWS.

Users will be able to download appropriate images for OpenStack, as well as ones usable on other public clouds where we don't have direct support.

Delivery Format

Images will be delivered as AMIs on Amazon EC2, as downloadable images in qcow2 and raw.xz formats, as vagrant images, and as installable ISO images. We may add other public cloud images and other downloadable formats to meet demand or anticipated need.


We are targeting 64-bit x86. As new community members join who are willing to maintain other architectures, we will add ARM and/or POWER images.


Fedora Atomic Host images, based on rpm-ostree technology, can be updated using the "atomic host upgrade" command. This is somewhat like a yum update, except it updates all of the content as an atomic unit. The content updates for Atomic Host will be released approximately every two weeks, including new ISOs and cloud images that can be used to create an Atomic Host. Updated content will be produced only for the current latest number release of Fedora and not for any previous releases of Fedora.

Measuring Success

Success looks like:

  • Increase in adoption.
  • Third party support / targeting of Fedora Atomic as a platform.
  • Increased contribution and participation in the Fedora Atomic WG and Fedora Project in general.
  • Creation of new stacks by third parties based on Atomic and OSTree.
  • Increase in the quality and quantity of Fedora containers using the Layered Build Service

User Profiles, Goals, and Primary Use Cases

User Profiles

There are three cloud user roles which describe the tasks of the people who interact with any cloud-based system:

  1. AWS enthusiast and Early Adopter
    • Writes and maintains a number of AWS-deployed applications including staging and production.
    • Works for a small start-up, primarily on his own. Automates as much as possible.
  2. DevOps Team Member
    • Uses the cloud to do Ruby on Rails development utilizing containers.
    • Works as part of a DevOps team responsible for all aspects of a set of applications.
    • Development, QA, and Production environments need to be identical.
  3. Web Developer
    • Concentrates on app development, not architecture, deployment, or operations.
    • Unlikely to care deeply about OS internals, cares that they can easily deploy the frameworks they want to use.
  4. Large-Environment Sysadmin
    • Interested in deploying self-service PaaS to lighten operational load
    • Will work closely with development team on deployment and development.
  5. Cloud-Native System Builder
    • Interested in Atomic as a building block in a custom cloud-native stack
    • Supporting a public website, HPC infrastructure, or more specialized infrastructure needs.
    • Possibly an ISV or SaaS vendor
  6. IoT Device Developer
    • Developing Internet of Things smart device which needs a full OS
    • Interested in Immutable Infrastructure more than containers
    • Heavy user of customized OStrees

Primary Use Cases

Containerized Web Application Deployment

Modern web applications are deployed as a collection of interconnected services, including parts like web servers, application servers, databases, and caching layers. Fault tolerance is handled at the overall orchestration level rather than by individual instances. Fedora Atomic can be the base of each of these parts, providing recent libraries, server software, and language toolchains via the Fedora container library. Each system will be managed using the public cloud's own management tools plus an orchestration system, such as OpenShift or Kubernetes.


  • Full support for installing/running up-to-date versions of Docker, Kubernetes, and/or OpenShift
  • Available catalog of open source applications, language stacks, and popular web platforms
  • Support for Continuous Integration/Continuous Delivery pipelines such as OpenShift and Fabric8

Automated Cloud-Native Infrastructure

System builders want redundant, fault-tolerant services for their internal infrastructure. The services are deployed and updated completely automatically using a combination of configuration management and orchestration. Fedora Atomic is an excellent platform for such efforts by supporting a varied set of container tools, as well as customization at the OSTree level. Not only do we support immutable, undifferentiated multi-host clusters, but because of the ability to layer Fedora's full set of packages, we can support whatever hardware or devices the user needs. Such infrastructure projects include:

  • providing networking via NFV containers,
  • offering database-as-a-service to other departments
  • deploying monitoring dashboards to support internal IT
  • running automated batch jobs as part of a big data pipeline

Requirements for Use Case:

  • Full support for installing/running up-to-date versions of Docker, Kubernetes, OpenShift, and runc.
  • Documentation and tools for users creating custom OSTrees for internal distribution.
  • Ability to install internal container registry.
  • Availability of ISO and VM images

Platform for Orchestration and PaaS

Both public service providers and internal large-company service providers need to offer "self-service" application hosting to their customers. They do this using OpenShift Origin or Kubernetes, which need an OS platform to run on for people building their own OpenShift or Kubernetes-based application clouds. Fedora Atomic is that OS, providing a stable, immutable base to run open source orchestration platforms on top of. One goal associated with this use case is providing and documenting an easy way to deploy OpenShift Origin on Fedora Atomic.


  • Full support for installing/running up-to-date versions of Docker, Kubernetes, and/or OpenShift
  • Clear documentation of orchestration cluster deployment process.
  • Ability to install internal container registry.
  • Availability of Atomic on public clouds, and VM images for OpenStack and similar.

Internet of Things

IoT vendors of "smart appliances" which require a full-featured OS need that OS to be (a) immutable and (b) update "atomically". That is, updates to the device OS should either succeed or fail but should not be able to partially succeed. This is what Fedora Atomic does, making it a leading candidate for provisioning such devices. Note that unlike the other use cases, IoT vendors might not use containers or orchestration at all; they may rely entirely on custom OSTree and layering cabilities to produce identical, atomic OSes for their devices. Fulfilling this particular use case will require branching out into other architectures, partcularly ARM32 and ARM64.


We aim to provide a comprehensive documentation covering users to developers. Should. Provide narrative documentation to make it easier to use cloud images and use them as foundations to new products. NTH. On a volunteer basis, we will maintain a knowledge base.

Fedora Project Documentation

The Atomic Working Group will cooperate with the Documentation Project to provide documentation to users, and developers of Fedora Cloud Products.

Open Source Projects documentation

Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...

About this Document

This PRD (Product Requirements Document) is an evolving document, created by the Fedora Atomic Working Group as part of the process for designing the Fedora Cloud product. The framework for the PRD itself is currently in a draft state. This document will evolve over time as the purpose of the working group continues to be determined as the working group process gets under way and initial products start to get produced.


Contributors to this document include:

Reviewers & Contributors

The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.


Some of the Cloud User Roles are based on “Description and Application of Core Cloud User Roles” ACM CHIMIT 2011, December 4 2011. Some aspects of Fedora Cloud personas are based on OpenStack personas (licensed under CC-By 3.0)

Community Information

The Fedora Atomic Working Group is one of many teams within the Fedora Project. The mailing list used for the Atomic Working Group is located here. Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.

Approval History

Over time, it is expected that this document will undergo various rounds of review, approval, and editing; in the future, it may be rewritten for different releases of Fedora. While one can review the history of a wiki document (by clicking the "history" tab), it is useful to provide explicit indicators of any major format changes, approvals, or indications of it being in a “final” state, in a list that can allow someone to quickly see that all of the prescribed layers of approval have occured.

  • February 15, 2017, mass revision of PRD to take into account shift from Cloud PRD to Atomic PRD. Current unapproved Draft
  • January 22, 2014: Approval by FESCo
  • January 8, 2014: Collaborative hackfest day.
  • October 28, 2013: Initial Draft of template.
  • FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes

Document Conventions

Definitions and Acronyms

  • AWS: Amazon Web Services
  • Amazon EC2: Amazon Elastic Compute Cloud, a popular public IaaS, part of AWS
  • IaaS: Infrastructure as a Service
  • PaaS: Platform as a Service
  • SaaS: Software as a Service
  • PRD: Product Requirements Document
  • EPEL: Extra Packages for Enterprise Linux
  • CI: Continuous Integration
  • CD: Continuous Delivery or Continuous Deployment
  • SCL: Software Collections
    teams in charge of some aspects of Fedora Project
  • NTH: Nice-to-have
  • BZ: Bugzilla
  • GUI: Graphical User Interface
  • CLI: Command Line Interface
  • API: Application Programming Interface
  • RDBMS: Relational DataBase Management System
  • FESCo: Fedora Engineering Steering Committee