From Fedora Project Wiki

< Changes

Revision as of 14:38, 11 June 2015 by Walters (talk | contribs) (Created page with "= Layered Docker Image Build Service <!-- The name of your change proposal --> = == Summary == Fedora currently ships a Docker base image, but Docker supports a layering conc...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Layered Docker Image Build Service

Summary

Fedora currently ships a Docker base image, but Docker supports a layering concept. There are some applications like Cockpit which we would like to ship as layered applications.

This change will deploy the [[1]] build service to support building and delivering a set of layered Docker images.

Owner

  • Release notes owner:

Current status

  • Targeted release: Fedora 23
  • Last updated: 2015-06-11
  • Tracker bug:

Detailed Description

(to fill in)

Benefit to Fedora

What is the benefit to the platform?

Docker is a very popular way to deliver container images. This will help deliver Fedora-based containers inside the Docker ecosystem, and other applications that are part of the Fedora package collection as containers.

Scope

  • Proposal owners: Proposal owners shall have to
    • define the syntax and semantics for new configuration parameters/files.
    • properly document how to test and configure the new default setup
    • persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications.
    • discuss with WGs in which products the change makes sense and what are the expectations of WGs for different Fedora products
    • resolve interoperability issues for Docker and other containers use-cases
  • Other developers: (especially NetworkManager and the likes)
    • No new features/workflow should be needed from other applications, since the use of trusted local DNS resolver should be seamless.
    • Ideally other developers and user should test their software and application in this setup and verify that it is working as expected
  • Release engineering:
    • would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc.
    • Add services needed for the setup into the default presets (dnssec-trigger and Unbound)
  • Policies and guidelines:
    • the chosen trusted DNS resolver package (Unbound) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention.
    • NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file.

Upgrade/compatibility impact

None.


How To Test

Ideally, we have a Fedora registry. If so, then adding it and doing:

{{{ atomic run registry.fedoraproject.org/cockpit }}}

User Experience

There's many potential roles interacting here - the container owner, the container user, release engineering.

Dependencies

  • N/A

Contingency Plan

People continue to upload to the Docker Hub in an ad-hoc fashion with no integration with Fedora.

Documentation

Needs filling in.

Release Notes