(Created page with '{{subst:Proposal}}') |
m (internal link cleaning) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Overview == | |||
Koji supports building LiveCDs and Appliances (raw disk images), this proposal seeks to integrate that functionality into the Fedora release process. | |||
=== Problem Space === | === 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 === | === 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 === | === 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 === | === 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. | |||
==== Configuration Changes ==== | |||
How to set up Fedora Koji for image building is [[Koji/BuildingImages|outlined here]]. Fedora Rel-Eng and the infrastructure team would need to follow the instructions therein. They would also need to adequately test to make sure the Koji functionality works as expected in the Fedora build system. | |||
==== | ==== 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 == | == 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? == | == Comments? == | ||
To leave a comment, use the Talk page for this proposal. | To leave a comment, use the Talk page for this proposal. | ||
Latest revision as of 21:51, 17 September 2016
Overview
Koji supports building LiveCDs and Appliances (raw disk images), this proposal seeks to integrate that functionality into the 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.
Configuration Changes
How to set up Fedora Koji for image building is outlined here. Fedora Rel-Eng and the infrastructure team would need to follow the instructions therein. They would also need to adequately test to make sure the Koji functionality works as expected in the Fedora build system.
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.