< Changes
No edit summary |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 53: | Line 53: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1397141 #1397141] | ||
== Detailed Description == | == Detailed Description == | ||
| Line 61: | Line 61: | ||
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. | 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 ' | For Fedora 26, we would like to produce an experimental variant as an optional part of the primary compose called 'ModularServer'. 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 'ModularServer' to be release blocking. Consider this an experiment. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 102: | Line 102: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* 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 | * 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 ModularServer build keeps failing - it shouldn't block the compose for other mainline variants. | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Beta freeze. | * Contingency deadline: Beta freeze. | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? No | * Blocks release? No | ||
* Blocks product? | * Blocks product? ModularServer | ||
== Documentation == | == Documentation == | ||
| Line 120: | Line 120: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF26]] | ||
<!-- 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 --> | ||
Latest revision as of 16:58, 12 December 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
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 'ModularServer'. 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 'ModularServer' 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 ModularServer build keeps failing - it shouldn't block the compose for other mainline variants.
- Contingency deadline: Beta freeze.
- Blocks release? No
- Blocks product? ModularServer