I think this will be a problem for us for our FCOS builds for the triple release (should happen tomorrow).

If possible it should suffice to unblock us to get one successful distrepo run in if we can manage that (maybe by temporarily removing the s390x builders from eligibility) while we investigate the root of the problem.

If we manage that here is the command I run to kick off the task:

koji dist-repo --non-latest coreos-pool 18B8e74c a15B79cc e99d6ad1 105ef944

The code has the same hard-coded channel that it always has had:

return make_task('distRepo', [tag, repo_id, keys, task_opts],
                 priority=15, channel='createrepo')

What is happening is that your channel policy is overriding the requested channel.

If you are going to have a custom channel policy, it is important that you avoid overriding the requested channel case unless you really mean it. Generally speaking that means you should have something like the following at or near the beginning of your channel policy.

has req_channel :: req
is_child_task :: parent

(these are the first two rules of the default channel policy).

It looks like someone has tried to limit who can use custom channels for build tasks, by altering the req rule to:

has req_channel && has_perm customchannel :: req

Unfortunately, this blocks situations where koji itself is passing an explicit channel to make_task().

You could either

1. either revert the req rule change or refactor it to be more specific
2. add explicit channel policy rules for these methods

Regardless, I strongly recommend that you have both the req rule and the parent rule at or near the top or the policy. Rules that override these should be rare and deliberate.

I don't see any change in koji 1.35 that would have affected how this channel policy is applied. When was the req rule in your policy changed?

The problem was that after 1.35, I deleted:

diff --git a/roles/koji_hub/templates/hub.conf.j2 b/roles/koji_hub/templates/hub.conf.j2
index 6ec02fced0..085f2032ce 100644
--- a/roles/koji_hub/templates/hub.conf.j2
+++ b/roles/koji_hub/templates/hub.conf.j2
@@ -129,7 +129,6 @@ tag =
 channel =
     method osbuildImage :: use osbuild
-    method newRepo distRepo buildSRPMFromSCM :: use createrepo
     method buildContainer :: use container
     method flatpakBuild :: use flatpak
     has req_channel && has_perm customchannel :: req

I am trying to see why the customchannel thing was added. It was back in 2018.

It looks like it was because with requested channels, someone could just request secure-boot and get a build moved onto those builders. ;(

So I could:

1. Just put:

2. method distRepo :: use createrepo

back

1. Grant the specific user(s) needing to do this the 'customchannel' perm

2. Something else/better? :)

In the mean time I just manually did a distrepo to unblock coreos (I have the permission)

and we can sort this out as time permits.

I would recommend the following

   has req_channel :: {
       # require customchannel to override build channel
       method build chainbuild !! req
       has_perm customchannel :: req
   }

There are only a few places where kojihub accepts a user specified channel -- build, chainbuild, maven, wrapperRPM, chainmaven, and winbuild. In Fedora, you have most of these disabled, so you only need to worry about only build and chainbuild. For other methods, you should be able to just take the requested channel.

that said, you can also just code the channel into the policy, as in your first option. I would avoid a solution that involves managing more user perms if possible.

That seems reasonable. I'll push that now...

ok. Pushed that. @dustymabe can you try some distrepos and see if they work as expected?

I'll kick one off.

It works!

Cool, so I think we can close this as not a koji bug/problem.

Thanks for the investigation!

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4263

Please continue any further discussion there.