As agreed on the last meeting I have implemented PoC of Koji hub policy that gives users with "pkglist" permission limited ability to manipulate package lists for certain Koji tags. The policy is deployed in staging Koji. Its configuration can be seen in Koji hub configuration file in ansible repository. No code changes to Koji are needed - configuration change is sufficient.

In current configuration:

• Removing packages is disallowed for all tags, as I think it is not desired in most cases - generally packages should be blocked instead of removing them. Users with admin permission can still remove packages by overriding this policy, eg. by adding --force argument to koji remove-pkg CLI call.
• Users with "pkglist" permission are allowed to:
  • in Fedora rawhide: add, unblock and block packages,
  • in Fedora branched before final freeze: add, unblock and block packages,
  • in Fedora branched during final freeze: add and unblock packages (blocking is not allowed),
  • in current F-n and previous F-(n-1) Fedora releases: add and unblock packages (blocking is not allowed),
  • in F-(n-2): nothing (I don't think it's wise to change package lists one month before EOL).
  • in EPEL 7: add, unblock and block packages,
• Users with "infra" permission are allowed to add, unblock and block pacakges in infra tags. This is not related to this ticket, but I wanted to show that the policy is able to express that, and I also think it may be a good idea to do.
• In all cases not listed above, users are denied to make changes to package lists for tags.

I'd like to highlight that the above policy rules are meant to be just examples/PoC. The actual rules are to be discussed and agreed on. Especially the part that disallows blocking packages during and after final freeze is meant mostly to show flexibility of the policy. Blocking packages in tags for released Fedora versions may be needed in some cases - for example when a package is blocked in f22, then to unblock it only in f28, but keep blocked in f29+ you need to both unblock it in f28 and at the same time block in f29, which would not be allowed by the above proposed policy rules.

The policy has been deployed in production Koji. Users with pkglist permission should be able to manipulate package lists in active Fedora tags.

@ignatenkobrain needs to have untagging ability as well. I am giving him admin and autosign permissions temporarily for now to fix rawhide. But we need to find a way to allow untagging as well.

From Igor:

[13:22:09] <ignatenkobrain> ⋊> ~/P/f/r/rpm on master ⨯ koji untag-build f31 rpm-4.14.90-0.git14653.1.fc31                                                                                               19:19:11
[13:22:09] <ignatenkobrain> 2019-06-10 19:19:33,550 [ERROR] koji: ActionNotAllowed: tag requires autosign permission

I've untagged broken RPM and also packages which were built using new RPM:

$ koji untag-build f31 perl-RPM-VersionCompare-0.1.1-30.fc31 libextractor-1.9-2.fc31 scl-utils-2.0.2-9.fc31 grubby-8.40-32.fc31 rpminspect-0.1-2.fc31 systemtap-4.2-0.20190605git8b868f3dd030.fc31 net-snmp-5.8-8.fc31 apt-0.5.15lorg3.95-36.git522.fc31

I've also created side tag to not break others' people builds.

So far I have used few more things in koji than I would otherwise have permissions by "policy":

• add-target/remove-target
• tag directly to f31 (merge tags) omitting f31-pending
• untag from f31
• add-tag
• regen-repo because it was not generated for more than 40 minutes

Please implement those before removing my admin permissions (or keep them since there were 2 +1s).

So far I have used few more things in koji than I would otherwise have permissions by "policy":

add-target/remove-target
tag directly to f31 (merge tags) omitting f31-pending

Do note that you have to be carefull there if everything is not signed it will break composes.

untag from f31

And here by policy you cannot untag something that has gone out in a rawhide compose.

add-tag
regen-repo because it was not generated for more than 40 minutes

This was likely due to the limit in kojira. It only does some number at a time. mbs seems to cause storms of them for some reason. ;(

Please implement those before removing my admin permissions (or keep them since there were 2 +1s).

Right.

Do note that you have to be carefull there if everything is not signed it will break composes.

I know. For things which are not signed, I tag them in f31-pending.

And here by policy you cannot untag something that has gone out in a rawhide compose.

I know and obviously I did not untag something what went into composes. I untagged sometghing what broke whole buildroot and prevented ANY composes :) That was RPM 4.15.

Ah, one more thing which I have used today. mass-tag.py from releng repo uses tagBuildBypass to speedup merging of big side tags. That usually won't be allowed for non-admins. This also needs to be configured properly.