#10394 Unretire script doesn't properly unretire packages
Opened 8 months ago by mattia. Modified 8 months ago

  • Describe the issue

See https://pagure.io/fedora-infrastructure/issue/10181

When unretiring a package a script which sets the package owner to the new user is run. As pointed in the infrastructure ticket linked above, the unretire script should also take care of removing any entry in the orphan_reason table of pagure-dist-git.

Either the script should be adjusted to take care of that, or the take_orphan endpoint of pagure-dist-git can be adjusted to take a 'user' parameter as input, so that the script can just use that endpoint.

  • When do you need this? (YYYY/MM/DD)


  • When is this no longer needed or useful? (YYYY/MM/DD)

  • If we cannot complete your request, what is the impact?

If a spurious entry remains in the orphan_reason table, users could (will) experience issues when trying to orphan the package again.

Metadata Update from @mohanboddu:
- Issue tagged with: low-gain, low-trouble, ops

8 months ago

@mattia Can you explain it a bit more, I think I am confused.


For the stand up meeting today

[14:16:59] <nirik> if you orphan a package via the button on src.fedoraproject.org... 
[14:17:05] <nirik> then someone takes it
[14:17:28] <nirik> or then it gets retired rather
[14:17:36] <nirik> then someone unretires it. 
[14:17:41] <nirik> and tries to orphan it 
[14:17:52] <nirik> it fails because there's still the old orphan reason

Is that what you meant?

Metadata Update from @mohanboddu:
- Issue untagged with: low-gain, low-trouble
- Issue tagged with: medium-gain, medium-trouble

8 months ago

@mohanboddu basically, when a package is orphaned, pagure-dist-git plugin adds an entry to the orphan_reason table.

Then, if a user un-orphan the package by the "take" button in web UI, the entry point takes care of assigning the package AND removing the entry in the orphan table.

From the infra ticket I linked above, it seemed that there were a lot of unretired packages which still had an entry in the orphan table. In that case, a user trying to orphan the package was unable to do so because pagure tries to add a new entry in the orphan table, but it found that there's already an entry for that project, thus it fails the unique key check.
I think this happens because the releng script used to un-retire and assign packages do not remove the entry in the orphan table. I may be wrong, but it seems reasonable. Recently un-retired packages by releng showed that spurious entry in the orphan table.

Thanks @mattia for the explanation, now I understood it properly.

Pinging @pingou to understand how to remove the orphan_reason so that we can implement it in unretiring process.

So looking at the pagure-distgit plugin I think updating take_orphan_endpoint with optional user parameter and updating our scripts to use it is the preferred way by me.

Login to comment on this ticket.

Boards 1
Ops Status: Backlog