On Wed, Jun 10, 2020 at 11:09:49AM +0200, Adrian Reber wrote:
Then I just have to wait a bit. No problem.
Having the possibility to generate the mirrorlist input data in about a minute would significantly reduce the load on the database server and enable us to react much faster if broken protobuf data has been synced to the mirrorlist servers on the proxies.
Yeah, and I wonder if it would let us revisit the entire sequence from 'update push finished' to updated mirrorlist server.
This would help us with the case of: - updates push/rawhide finishes, master mirror is updated. - openqa/other internal thing tries to get images or updates in that change and gets a metalink with the old checksum so it can't get the new stuff. - mm-backend01 generates and pushes out a new protobuf.
Probably. As the new code will not run on the current RHEL 7 based mm-backend01 would it make sense to run a short running service like this on Fedora's OpenShift? We could also create a new read-only (SELECT only) database account for this.
We could, or as smooge suggests make a mm-backend02?
But I guess now mm-backend02 just generates new proobuf files and copies them to mirrorlists? If thats all it's doing, perhaps we could indeed replace it with an openshift project.
kevin