Learn more about these different git repos.
Other Git URLs
With the recent change in Modularity, modules will be built against the traditional fedora buildroot. To make the buildroot visible for MBS, we need to create new module entries in PDC defining a "fake" module that will point to the fedora buildroot.
We decided to name the module 'platform' and it's streams 'f27', 'f28', 'f29', etc. This, however, conflicts with the existing platform modules from the previous attempts, so we need to delete those.
I'm asking for:
Delete all platform module entries from PDC. That means deleting all unreleased variant entries having 'variant_name' == 'platform'.
Create a platform:f28 module entry in PDC. That means creating the following unreleased variant entry:
{ "variant_id": "platform", "variant_uid": "platform-f28-1", "variant_name": "platform", "variant_type": "module", "variant_version": "f28", "variant_release": "1", "koji_tag": "f28", "modulemd": "document: modulemd\nversion: 1\ndata:\n name: platform\n stream: f28\n version: 1\n summary: 'Fedora 28 traditional base'\n description: 'Fedora 28 traditional base'\n profiles:\n buildroot: \n rpms: [bash, bzip2, coreutils, cpio, diffutils, fedora-release, findutils, gawk, gcc, gcc-c++,\n grep, gzip, info, make, patch, redhat-rpm-config, rpm-build, sed, shadow-utils, tar, unzip,\n util-linux, which, xz]\n srpm-buildroot:\n rpms: [bash, fedora-release, fedpkg-minimal, gnupg2, redhat-rpm-config, rpm-build, shadow-utils]", "runtime_deps": [], "build_deps": [], "active": true, "rpms": [] }
For better readability of the modulemd I have included in the entry above, here is a more readable version:
document: modulemd version: 1 data: name: platform stream: f28 version: 1 summary: 'Fedora 28 traditional base' description: 'Fedora 28 traditional base' profiles: buildroot: rpms: [bash, bzip2, coreutils, cpio, diffutils, fedora-release, findutils, gawk, gcc, gcc-c++, grep, gzip, info, make, patch, redhat-rpm-config, rpm-build, sed, shadow-utils, tar, unzip, util-linux, which, xz] srpm-buildroot: rpms: [bash, fedora-release, fedpkg-minimal, gnupg2, redhat-rpm-config, rpm-build, shadow-utils]
For the Bootstrap module we also needed a minimal xmd block for MBS. I don't know if that is still required nowadays.
xmd
/cc @mprahl, @ralph
I'm also wondering whether simply dropping all existing module records would make things easier. We won't need them anyway.
f28-build might be a better choice for koji_tag, too. I'd appreciate if someone knowledgeable can confirm this :)
f28-build
koji_tag
Metadata Update from @ralph: - Issue assigned to ralph
For the Bootstrap module we also needed a minimal xmd block for MBS. I don't know if that is still required nowadays. /cc @mprahl, @ralph I'm also wondering whether simply dropping all existing module records would make things easier. We won't need them anyway.
I'm fine with dropping all existing module records in PDC. We can consider doing that in MBS as well, but we'd have to untag all module RPM builds in Koji, so that Koji GC cleans them up (MBS does this on old failed modules for us already).
Also, the xmd block is still required for component reuse. If this new platform module is a "fake module", that means it won't have a modulemd in a git repo, which means it won't have a commit hash in xmd for MBS to determine if the build dependencies changed. We can change the default rebuild strategy for Fedora's MBS to match the Red Hat MBS to be "only-changed", which would not look at if dependencies have changed, therefore, not requiring platform to have a commit hash.
I can take this work. I will use the scripts in the bootstrap/ dir of the fm-orchestrator git repo.
bootstrap/
active=False
Good point with the rebuild policy. I thought we're going for "only-changed" since the base is so huge it would force rebuild all the time.
So I would personally go for "only-changed", and in case a packager needs a full rebuild, they can specify that manually. We can make it more clever later.
De-activating the modules should be fine. If we do that, we should probably keep the tags too.
Regarding xmd, if we don't need it, let's not put it in there. I hope MBS doesn't blindly access values in it, though.
On the policies, switching to "only-changed" means we won't track changes in modules (other than the new fake base) but I suppose that's alright and simplifies things a bit.
@ralph, could you deactivate all existing modules then?
could you deactivate all existing modules then?
Yes.
Here's the new entry: https://pdc.fedoraproject.org/rest_api/v1/unreleasedvariants/platform-f28-1/
I'm still de-activating all of the ~900 active module builds. The approach I chose is taking a while to run.
@ralph can you please add a requires key in xmd['mbs'] and have the value be an empty dict?
Oh, shoot. I ran into a problem I'd forgotten about:
First, with the PDC record, the MBS is now configured to build modules requesting "platform-f28" against the "f28-build" tag. However, MBS has a configured policy in place to stop it from touching any tag that doesn't start with the prefix "module". I could change this configuration, to let it touch the "f28-build" tag, but we put this guard in place for a reason. MBS has elevated privileges, and we wanted to protect the traditional tags from it.
So, that's one option. We could just let MBS rely on "f28-build".
A second option, we could create an intermediary tag, called "f28-modular-build" which inherits from "f28-build", and MBS could depend on that instead.
Thoughts?
(for now, @puiterwijk suggests we go with "module-f28-build" as the intermediary...)
OK, that tag is created. Module builds end up looking like this now:
λ koji list-tag-inheritance module-f93325dc033dff68-build module-f93325dc033dff68-build (3311) └─module-f28-build (3307) └─f28-build (1928) └─f28-override (1922) └─f28-updates (1916) └─f28 (1913)
Going to close this one for now. We have a new issue to deal with in fm-orchestrator#830.
Metadata Update from @ralph: - Issue status updated to: Closed (was: Open)
Thanks, @ralph !
Login to comment on this ticket.