From Fedora Project Wiki
(Undo revision 488703 by Stefw (talk))
 
(4 intermediate revisions by 3 users not shown)
Line 30: Line 30:
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: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1397142 #1397142]


== Detailed Description ==
== Detailed Description ==
Line 63: Line 63:
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
* Policies and guidelines: Note that we do not think there are any packaging guidelines that will need to be changed in the Fedora 26 timeline.  We would like to change the branching structure in pkgdb and dist-git in the Fedora 27 release cycle (with a separate Change document).  We furthermore will need to submit new Module Guidelines that describe best practices and requirements for writing and maintaining modulemd definitions - similar to how the Packaging Guidelines describe best practices and requirements for writing and maintaining .spec files.  We would like to avoid writing those Module Guidelines for the F26 cycle and instead limit the number of trusted module maintainers to a small subset of the Modularity Working Group.  Once they have experience building the base modules, we'll use that experience to inform the docs we write for F27, at which time we'll open up the Module Build Service to the rest of the community.
* Policies and guidelines: Note that we do not think there are any packaging guidelines that will need to be changed in the Fedora 26 timeline.  We would like to change the branching structure in pkgdb and dist-git in the Fedora 27 release cycle (with a separate Change document).  We furthermore will need to submit new Module Guidelines that describe best practices and requirements for writing and maintaining modulemd definitions - similar to how the Packaging Guidelines describe best practices and requirements for writing and maintaining .spec files.  We would like to avoid writing those Module Guidelines for the F26 cycle and instead '''limit the number of trusted module maintainers''' to a small subset of the Modularity Working Group.  Once they have experience building the base modules, we'll use that experience to inform the docs we write for F27, at which time we'll open up the Module Build Service to the rest of the community.  Note that the restrictions on who can use the module build service ''will not be lifted'' until policies and process around creating new modules have been approved by the FPC (or FESCo).
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
Line 107: Line 107:
-->
-->


[[Category:ChangeReadyForFesco]]
[[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 14:05, 23 March 2017

Module Build Service

Summary

We will deploy an instance of the Module Build Service to production in Fedora Infrastructure. Other teams will use this service to produce some "modular" content for the Fedora 26 release.

Owner

  • Name: Ralph Bean
  • Email: rbean@redhat.com
  • Release notes owner:
  • Responsible WG: Modularity

Current status

Detailed Description

We will deploy an instance of the Module Build Service (MBS) to production in Fedora Infrastructure. Other teams will use this service to produce some "modular" content for the Fedora 26 release.

In short, the MBS is a workflow orchestration service on top of koji. When a user submits a request for a new module build:

  • A new tag is created in koji for that module build.
  • A module-build macros package is synthesized and built in the new buildroot.
  • The buildroot is linked with other module tags that it has declared dependencies on.
  • RPMs to be included in the module are rebuilt from source in the new tag.
  • Kojira generates a yum/dnf repo from the new tag.

The compose tooling (pungi) will then pick up this tag and possibly include it in variants for the compose.

For the Fedora 26 timeframe, we will lock down the users who can submit to the MBS to a small number of Modularity WG members. This is not ideal, but the thought is that we want to limit the amount of spam that the MBS will impose on the production koji instance - we don't want to interfere with the general release of Fedora 26.

In the Fedora 27 timeframe, we will open it up to all packagers after we're sure MBS is sophisticated enough to throttle itself appropriately.

Benefit to Fedora

See the Modularity page for argument.

Scope

  • Proposal owners: We are responsible for the development, deployment, and maintenance of the Module Build Service itself. We have a prototype already functioning. At the time of writing, we still need to harden it for production, and have it vetted for deployment by Release Engineering and Fedora Infrastructure.
  • Other developers: We don't think that other developers will have to make changes in response to this effort. The Base Runtime team (a sub-team of the Modularity Working Group) will be working to prepare content to be built in the Module Build Service.
  • Release engineering: In order to make use of the Module Build Service, we will need changes to pungi to pull rpms for a variant from the koji tags created by the Module Build Service, but that is a separate Change proposal. The owners of this proposal intend to do that work ourselves in consultation with Release Engineering.
  • Policies and guidelines: Note that we do not think there are any packaging guidelines that will need to be changed in the Fedora 26 timeline. We would like to change the branching structure in pkgdb and dist-git in the Fedora 27 release cycle (with a separate Change document). We furthermore will need to submit new Module Guidelines that describe best practices and requirements for writing and maintaining modulemd definitions - similar to how the Packaging Guidelines describe best practices and requirements for writing and maintaining .spec files. We would like to avoid writing those Module Guidelines for the F26 cycle and instead limit the number of trusted module maintainers to a small subset of the Modularity Working Group. Once they have experience building the base modules, we'll use that experience to inform the docs we write for F27, at which time we'll open up the Module Build Service to the rest of the community. Note that the restrictions on who can use the module build service will not be lifted until policies and process around creating new modules have been approved by the FPC (or FESCo).
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The existence of the MBS shouldn't affect upgrades and compatibility for end-users.

How To Test

If we can produce yum/dnf repos in koji from a modulemd file without impacting the regular build process, then this is a success.

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: If it looks like we won't have this ready in time for F26, we can simply kill it.
  • Contingency deadline: Beta freeze.
  • Blocks release? No
  • Blocks product? We're considering proposing an experimental modular product, to be produced alongside the traditional Fedora.NEXT products. Failure to implement and deploy the MBS would block the release of that experimental modular product.

Documentation

Modularity/Infra

Release Notes