From Fedora Project Wiki
(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...")
 
No edit summary
Line 43: Line 43:
== Scope ==
== Scope ==
* Proposal owners: Proposal owners shall have to
* Proposal owners: Proposal owners shall have to
** define the syntax and semantics for new configuration parameters/files.
** Deploy OSBS
** 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)
* Other developers:  
** 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:
* 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.
** Deploy OSBS
** Add services needed for the setup into the default presets (dnssec-trigger and Unbound)


* Policies and guidelines:  
* 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.
** Need to determine who can submit/build images
** 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.
** Determine who is responsible for building/testing images as RPMs change
** Determine policy for non-RPM content


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

Revision as of 17:28, 11 June 2015

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
    • Deploy OSBS
  • Other developers:
  • Release engineering:
    • Deploy OSBS
  • Policies and guidelines:
    • Need to determine who can submit/build images
    • Determine who is responsible for building/testing images as RPMs change
    • Determine policy for non-RPM content

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Layered_Docker_Image_Build_Service&oldid=415303"