< Changes
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...") |
No edit summary |
||
| Line 120: | Line 120: | ||
--> | --> | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Revision as of 15:07, 4 November 2016
Modular Compose
Summary
For Fedora 26, we would like to modify the compose tools (pungi) to produce an additional experimental variant, derived from modules built in the Module Build Service.
Owner
- Name: Ralph Bean
- Email: rbean@redhat.com
- Release notes owner:
- Responsible WG: Modularity
Current status
- Targeted release: Fedora 26
- Last updated: 2016-11-04
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
As described in another change proposal, we are going to implement and stand up a Module Build Service (MBS). Once we have a built module (a side-tag in koji with a corresponding yum/dnf repo), we would like to be able to do something with it:
The point of this change is to modify the existing compose tool used by Release Engineering (pungi) so that it can consume content for a new variant from the MBS.
For Fedora 26, we would like to produce an experimental variant as an optional part of the primary compose called 'CrazyServer'. We want it to be produced alongside the now-traditional 'Server', 'Workstation', and 'Cloud' variants, using the same tools. In the event of failure, we don't want 'CrazyServer' to be release blocking. Consider this an experiment.
Benefit to Fedora
See Modularity for a broader justification. The point here is that before we go whole-hog into Modularity, we would like to produce minimal base images as a part of the real compose to make sure everything is going to work. We have more radical changes we would like to make in the F27 cycle (changes to dist-git branching model, continuous integration back to dist-git pull requests, etc..).
Scope
- Proposal owners: We need to modify pungi to consume content from the MBS.
- Other developers: N/A (not a System Wide Change)
- Release engineering: We will need to work with Release Engineering to debug any problems we inadvertently introduce.
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The new experimental variant shouldn't have any impact on upgrades or compatibility for end-users.
How To Test
We will need the base-runtime team (a sub-team of the Modularity Working Group) to define some basic criteria to see if the images we produce are valid.
User Experience
N/A (not a System Wide Change)
Dependencies
This depends on Changes/ModuleBuildService.
Contingency Plan
- Contingency mechanism: If this fails for any reason, we can simply revert the changes in pungi. Pungi already has to ability to treat some variants as *optional*, which we intend to leverage. If the CrazyServer build keeps failing - it shouldn't block the compose for other mainline variants.
- Contingency deadline: Beta freeze.
- Blocks release? No
- Blocks product? CrazyServer