Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

coreos-koji-tagger: query packages directly in intermediate tag #85

Open
jlebon opened this issue Mar 10, 2020 · 2 comments
Open

coreos-koji-tagger: query packages directly in intermediate tag #85

jlebon opened this issue Mar 10, 2020 · 2 comments

Comments

@jlebon
Copy link
Member

jlebon commented Mar 10, 2020

Right now, the tagger doesset(coreos-pool) - set(lockfile-packages) to know which builds to tag into the intermediate (signing) tag. And then it waits for 10m for the builds to get signed. However, as we've seen, 10m might not be long enough.

ISTM how long RoboSignatory takes to sign packages shouldn't affect coreos-koji-tagger. Instead of waiting for the build to be signed, instead it should do (set(coreos-pool) U set(f31-coreos-signing-pending)) - set(lockfile-packages). I.e. it should consider packages in queue to be signed as if they're already tagged. That should simplify its logic and make it indifferent to how busy RoboSignatory is.

@dustymabe
Copy link
Member

we must wait until the package is signed before requesting a new distrepo (yum repo). Otherwise the yum repo won't have the package in it.

@jlebon
Copy link
Member Author

jlebon commented Mar 10, 2020

we must wait until the package is signed before requesting a new distrepo (yum repo). Otherwise the yum repo won't have the package in it.

Ahh right, that's an important detail.

Hmm, I think then what we could do is have a separate thread that just waits for the signing tag to be empty before starting a new distRepo task. IOW, we completely decouple those two parts of the app. That way for example the tagger can just keep processing messages while RoboSignatory is busy, and we'll get to regenerating the repo once it gets to our requests. But yeah, that increases complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants