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

Targeted release: Fedora 26
Last updated: 2017-03-23
Tracker bug: #1397142

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.
- List of deliverables: N/A (not a System Wide Change)
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

@@ Line 1: / Line 1: @@
-= Standard Dicsovery, Packaging, Invocation of Integration Tests =
+= Module Build Service <!-- The name of your change proposal --> =
-{{admon/warning|This is incomplete|This file is incomplete.}}
-{{admon/warning|This is a proposal|Feedback is more than welcome.
-There's a ''discussion'' tab above.}}
 == Summary ==
-What follows is a standard way to discover, package and invoke integration
+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.
-tests for a package stored in a Fedora dist-git repo.
 == Owner ==
-* Name: [[User:Stefw| Stef Walter]]
+* Name: [[User:Ralph| Ralph Bean]]
-resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
+<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
-* Email: stfw@fedoraproject.org
+* Email: rbean@redhat.com
-* Name: ''Looking for a co-owner''
 * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
+<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
+* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
+-->
+<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
+* Product:
+-->
+* Responsible WG: Modularity
+== Current status ==
+* Targeted release: [[Releases/26 | Fedora 26 ]]
+* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
+<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
+Bugzilla states meaning as usual:
+NEW -> change proposal is submitted and announced
+ASSIGNED -> accepted by FESCo with on going development
+MODIFIED -> change is substantially done and testable
+ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
+CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
+-->
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1397142 #1397142]
 == Detailed Description ==
-Many Fedora packages have unit tests. These tests are typically run during a
+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.
-<code>%check</code> RPM build step. These tests run in the build root in which
-the package is built and may involve the <code>BuildRequire</code> dependencies.
-On the other hand, integration testing happens against a composed system.
+In short, the MBS is a workflow orchestration service on top of koji.  When a user submits a request for a new module build:
-Several upstream projects have integration tests, but these integration tests have
-typically not been used or packaged in Fedora. Both Fedora QA and the Atomic Host
-team would like to create more integration tests, stored in dist-git, and use a CI
-system to run them on Fedora packages.
-What follows is a standard way to discover, package and invoke integration
+* A new tag is created in koji for that module build.
-tests for a package stored in a Fedora dist-git repo.
+* 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.
-It is important that the CI system which runs the test is independent from the
+The compose tooling (pungi) will then pick up this tag and possibly include it in variants for the compose.
-layout of the test themselves.
-'''Goals:'''
+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.
- * Implementation details of the integration testsuite or its framework should not leak into or rely on the CI system invoking the test.
+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.
- * CI system implementation details should not leak into the testsuite or its metadata.
- * It should be possible to change the CI system that runs a testsuite.
- * It should be possible for a dist-git packager to run a testsuite locally.
-What follows is a standard way to discover, package and invoke integration
+== Benefit to Fedora ==
-tests for a package stored in a Fedora dist-git repo.
-The integration tests are packaged and delivered through Fedora as
+See the [[Modularity]] page for argument.
-<code>%{name}-tests</code> subpackages of the package they are associated with.
-=== Packaging ===
+== 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.
+<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+* 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 [[Changes/ModularCompose | separate Change proposal]].  The owners of this proposal intend to do that work ourselves in consultation with Release Engineering.
+<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.
+Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
+** [[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 -->
+* 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. -->
+* Trademark approval: N/A (not needed for this Change)
+<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
-Each dist-git repo that has integration tests should package those tests in a
+== Upgrade/compatibility impact ==
-<code>%{name}-tests</code> subpackage. This is similar to the
-<code>%{name}-debuginfo</code> or <code>%{name}-docs</code> subpackages we have
-today.
-The spec file for a dist-git repo may include upstream integration tests into
+<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-its <code>%{name}-tests</code> subpackage. The spec file may also include tests
+The existence of the MBS shouldn't affect upgrades and compatibility for end-users.
-directly from files in <code>tests/</code> subdirectory of the dist-git repo itself.
-=== Invocation ===
+== How To Test ==
-To invoke the testsuite, the subpackage is installed. Each integration testsuite
+If we can produce yum/dnf repos in koji from a modulemd file without impacting the regular build process, then this is a success.
-that is included in installs an executable in the path <code>/usr/tests/</code>.
-To invoke the integration test suites, one would:
+== User Experience ==
+<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
+<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+N/A (not a System Wide Change)
- * Place the artifact being tested, usually RPM files, in <code>/var/cache/tests/</code>
+== Dependencies ==
- * Execute all executable files in <code>/usr/tests/</code> one at a time.
+<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
-  * Treat the stdout/stderr of each testsuite process as the testsuite result log.
-  * Examine the exit code of each testsuite process. Zero exit code is success, non-zero is failure.
-  * The testsuites place result artifacts like screenshots in <code>/var/log/tests/</code>
- * The testsuite is invoked as root, and may drop privileges as desired
- * The testsuite is invoked with a working directory of <code>/</code>
-Multiple subpackages may be installed as long as their dependencies do not conflict.
+<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+N/A (not a System Wide Change)
-=== Staging ===
+== Contingency Plan ==
-The <code>%{name}-test</code> subpackage should <code>Requires:</code> all other packages
+<!-- 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.  -->
-that the testsuite executable needs in order to run. This includes libraries or frameworks,
+* Contingency mechanism:  If it looks like we won't have this ready in time for F26, we can simply kill it.
-or subsystems like <code>libvirt</code>.
+* 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.
-Some integration tests may choose to test in-situ, on the system on which the testsuite
+== Documentation ==
-is installed. In these cases the <code>%{name}-tests</code> subpackage should directly
-depend on the package being tested.
-More rigourous integration tests test an integrated system from the outside. It is the
-responsibility of the <code>%{name}-tests</code> subpackages to provision virtual
-machines or containers necessary to do such testing. In almost all cases this will happen
-by way of a provisioning framework such as Avocado, Ansible, Module Testing Framework,
-linch-pin, etc.
-=== Discovery ===
-A <code>check</code> file in a dist-git repo should list the various names of
-packages that should be installed in order to run the integration tests for that
-package. If this file is empty then the list of packages will default to
-<code>%{name}-tests</code>.
-The format of this file has not yet been defined, but a simple text file similar
-to sources listing package N[VR]'s may suffice.
-== Scope ==
-This change requires no changes to Fedora infrastructure itself. It is limited
-to changes in dist-git repos. However certain key infrastructure changes could
-mitigate usability or side-effects of this change.
-== Benefit to Fedora ==
-Developers benefit by having a consistent target for how to describe tests,
-while also being able to execute them locally while debugging issues or
-iterating on tests.
-By packaging, staging and invoking tests consistently in Fedora we create an
-create an eco-system for the tests that allows varied testsuite frameworks as
-well as CI system infrastructure to interoperate. The integration tests
-outlast the implementation details of either the frameworks they're written
-in or the CI systems running them.
-== User Experience ==
-Users benefit by having tests that they can reproduce on their own systems.
-They can install the similar to how they consume <code>%{name}-doc</code>
-or <code>%{name}-debuginfo</code> subpackages today.
-We may choose to avoid having such packages available in the standard repositories.
-We may choose to only have them in <code>updates-testing</code> or an
-arrangement similar to <code>debuginfo</code>. These choices will require some
-markup and/or change to infrastructure.
-== Upgrade/compatibility impact ==
-Although there may already be subpackages that are named
+[[Modularity/Infra]]
-<code>%{name}-tests</code> this is merely a convention, and such packages will
-not affect the behavior of this proposal.
-== Examples ==
+== Release Notes ==
+<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
+<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
-TODO: Build out this section
+Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
+-->
-== Notes ==
+[[Category:ChangeAcceptedF26]]
+<!-- When your change proposal page is completed and ready for review and announcement -->
+<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
+<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
+<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
- * ...
+<!-- Select proper category, default is Self Contained Change -->
- * ...
+[[Category:SelfContainedChange]]
+<!-- [[Category:SystemWideChange]] -->

Search

Changes/ModuleBuildService: Difference between revisions