From Fedora Project Wiki

(Created page with '{{subst:Proposal}}')
 
No edit summary
Line 1: Line 1:
<!-- This is the FESCo proposal template.  It is not necessary that you use this template but it is encouraged that you do.  It will help FESCo focus on the issue being addressed and the parts that need discussion, as well as identify the scope of the proposal. You may remove all these comment sections from your proposal. -->
== Overview ==


== Overview ==
Koji supports building LiveCDs and Appliances (raw disk images), this proposal seeks to integrate that functionality into Fedora release process.


=== Problem Space ===
=== Problem Space ===
<!-- Describe the problem this proposal seeks to solve -->
Today Fedora remixes, spins, and cloud images are all generated on the side, outside of Rel-Eng control and visibility. There is little in the way of reproducibility or logging when the images are generated.


=== Proposed Solution ===
=== Proposed Solution ===
<!-- Describe proposed solution in detail -->
Koji supports building LiveCDs and Appliances as of the 1.4 release, which is what Fedora Koji is. With a little configuration effort a small set of contributors can be able to build their images in Koji. Building images in Koji carries with it a lot of the same benefits as building RPMs: they're built consistently, in a controlled environment, and with plenty of logging and traceability.


=== Scope ===
=== Scope ===
<!-- Describe the scope of any project work or properties that will be affected by the proposal -->
This proposal impacts the Cloud SIG, Spins SIG, Fedora Rel-Eng and the infrastructure team. It does not require functional enhancements to existing software, but it does require configuration changes in Fedora Koji, additional policy, and SOP.


=== Active Ingredients ===
=== Active Ingredients ===
<!-- A list of any prerequisites or other materials needed to implement the solution -->


==== Component 1 ====
==== Hardware Considerations ====
<!-- The first of a list of prerequisites, and what exactly needs to be done with it -->
Images take up space and generate load on the builders. Depending on the volume of images to be generated it may warrant hardware considerations.
 
==== Koji Stack ====
Koji, livecd-tools, appliance-tools, mock, yum and RPM are all involved here. No functional changes need to be made, but the Fedora community should be very involved with changes to those packages so that any changes that break Fedora's image building processes can be discovered early and the risks mitigated. (this involvement may already be adequate, just making sure it is highlighted)


==== Component 2 ====
==== New SOPs ====
<!-- The second of a list of prerequisites, and what exactly needs to be done with it. Add more subsections as needed for additional components. -->
SOPs would need to be defined that designate responsible parties for image builds, who can initiate them, how to initiate them, and what to do with them after they're built.


== Discussion Points ==
== Discussion Points ==
<!-- Describe things which should be discussed regarding the proposal.  Specifics that need narrowing down, or contentions parts of the proposal. -->
 
* Who should own building the images?
* What should the policy around building test/production images be?
* Which images should be built in Koji? All spins and cloud images?
* Are there any hardware considerations, such as space and load on the builders?


== Comments? ==
== Comments? ==

Revision as of 19:19, 1 October 2010

Overview

Koji supports building LiveCDs and Appliances (raw disk images), this proposal seeks to integrate that functionality into Fedora release process.

Problem Space

Today Fedora remixes, spins, and cloud images are all generated on the side, outside of Rel-Eng control and visibility. There is little in the way of reproducibility or logging when the images are generated.

Proposed Solution

Koji supports building LiveCDs and Appliances as of the 1.4 release, which is what Fedora Koji is. With a little configuration effort a small set of contributors can be able to build their images in Koji. Building images in Koji carries with it a lot of the same benefits as building RPMs: they're built consistently, in a controlled environment, and with plenty of logging and traceability.

Scope

This proposal impacts the Cloud SIG, Spins SIG, Fedora Rel-Eng and the infrastructure team. It does not require functional enhancements to existing software, but it does require configuration changes in Fedora Koji, additional policy, and SOP.

Active Ingredients

Hardware Considerations

Images take up space and generate load on the builders. Depending on the volume of images to be generated it may warrant hardware considerations.

Koji Stack

Koji, livecd-tools, appliance-tools, mock, yum and RPM are all involved here. No functional changes need to be made, but the Fedora community should be very involved with changes to those packages so that any changes that break Fedora's image building processes can be discovered early and the risks mitigated. (this involvement may already be adequate, just making sure it is highlighted)

New SOPs

SOPs would need to be defined that designate responsible parties for image builds, who can initiate them, how to initiate them, and what to do with them after they're built.

Discussion Points

  • Who should own building the images?
  • What should the policy around building test/production images be?
  • Which images should be built in Koji? All spins and cloud images?
  • Are there any hardware considerations, such as space and load on the builders?

Comments?

To leave a comment, use the Talk page for this proposal.

Retrieved from "https://fedoraproject.org/w/index.php?title=KojiImages&oldid=200380"