On Mon, Nov 7, 2016 at 4:13 AM, Jan Kurik <jkurik(a)redhat.com> wrote:
= Proposed Self Contained Change: Module Build Service =
https://fedoraproject.org/wiki/Changes/ModuleBuildService
Change owner(s):
* Ralph Bean <rbean(a)redhat.com>
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.
== 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.
Can you explain this in more detail?
How do layered modules work here? Is that what you mean by "buildroot
is linked with other module tags"?
Can modules built via MBS span releases, or are you strictly limiting
it to the f26 repos for base packages? (E.g. can a module declare a
dependency on an older package found in f25 and have it rebuilt into
the module repo?)
If all packages in a module are rebuilt from source, and we have a
variety of modules that all include the packages, doesn't this
increase the storage requirements over what we have today
significantly?
Are modules built on all architectures? (The answer should be yes,
otherwise we will face significant boot strapping issues.)
* 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.
Throttle?
== 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
[
https://fedoraproject.org/wiki/Changes/ModularCompose]. The owners of
this proposal intend to do that work ourselves in consultation with
Release Engineering.
Is this being done in staging to start with?
* 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.
I think f27 is an aggressive target, but it's possible. The
documentation and policies are key here, and those need to be done
well in advance of general availability.
josh