@gotmax23 told me that this uses https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/plugin.py#_50 which means fedpkg retire now requires admin permission, while the retirement commit only requires dist-git write access.

Hence, I think fedpgk retire should only operate on git level (as it did before this change) and the toddler that updates PDC based on the commit should disable monitoring instead.

Hence, I think fedpgk retire should only operate on git level (as it did before this change) and the toddler that updates PDC based on the commit should disable monitoring instead.

I agree; a packager should not need admin ACLs to retire a package and the error message should be more useful. For example, https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves assumes that provenpackagers and users/group members with commit can properly retire packages. I wanted to handle this myself to save releng's time.

https://pagure.io/fedpkg/c/7f1b8c75a718a6a54343dc2dcd5b51efefd91ea8?branch=master is where this was added to fedpkg.

I agree, I should have been more clear with informing the user, that he needs a specific ACL
The information could be seen in fedpkg disable-monitoring --help, but it wasn't obvious. Sorry for that.
But now it seems it doesn't make sense to fix it, right?
Should I remove the functionality then?
cc @lenkaseg (feature requestor)

While I understand why this might sound like a good thing to move to toddlers, I think we should do the operation when we have the opportunity. It is one POST request vs, emitting a message, consuming the message, parsing it, and creating the POST request.

We can always relax the ACL on release monitoring change. Making in committer instead of admin.

In any case, fedpkg retire should have a CLI flag to prevent disabling monitoring.

If not disabling the monitoring can lead to trouble, a fedpkg-powered solution won't be good, because it's possible to retire packages in dist-git by simply committing and pushing the dead.package commit (and because currently when the token is not good enough, the dist-git retirement happens anyway and the disablement of monitoring does not happen).

A toddler that handles retirements in dist-git and propagates them to PDC already exists anyway.

Just to add info here. The flow currently is a bit confusing...

• maintainer submits a git commit with 'dead.package' in it. (ie, fedpkg retire)
• a toddler sees that, updates the sla/eol in pdc
• The next time branched or rawhide compose runs, they run the block_retired script that looks up all retired packages from pdc and blocks them in koji.

So, I think we could extend the toddler that does the pdc updating to perhaps also update monitoring?

we could extend the toddler that does the pdc updating to perhaps also update monitoring?

That is what I meant as well (in case I was not clear enough).

This continues to confuse even experienced packagers, see https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/5ELR4R6UFWW7HAW3PEVKW77GH22OIJM7/

I tried to make it more clear by adding some extra description.
https://pagure.io/fedpkg/pull-request/530

But if the disable-monitoring functionality should be placed elsewhere, I am not against removing it from fedpkg.

disable-monitoring functionality could stay here in case folks want to explicitly use it. However, is should not be a necessary part of retirement driven by the "client" -- if disabling monitoring is an essential part of retirement, it should happen when the PDC/koji retirement happens.

Ok, I modified the retire functionality then. disable-monitoring is now separated from retire and can be run only manually if desired.
https://pagure.io/fedpkg/pull-request/530

Commit 9dea9969 fixes this issue

We had a similar issue that got opened at releng: https://pagure.io/releng/issue/12128