Limit gru tasks
We right now schedule one limit_assets and one limit_results job for every ISO posted. Which was fine when all ISOs
posted were either TW or SLES builds - i.e. rarely.
But now we see dozens of incidents posted as ISO per hour - and the GRU is not able to run them as quickly. And fact is,
the actual task is a global one, so there is no need to do this more often than once in a while. We can't really decouple
it from the actual load, but binding it to ISO posts sounds wrong too.
Just brainstorming possibly solutions:
- keep binding it to ISO post, but make sure there is only one of such job around
- only trigger the task on every Xth job created (where X could be 1000 or generally configurable)
this is mildly urgent as I'm removing 1000 gru tasks daily from the backlog
#7 Updated by EDiGiacinto almost 2 years ago
- Status changed from In Progress to Resolved
- Target version changed from Current Sprint to Done
We have now a ttl mechanism ( https://github.com/os-autoinst/openQA/pull/1637 ) to be sure that very old tasks ( 2 days ) are not executed, but with the recent optimizations by coolo and the Minion migration ( with error handling ) this became just a failsafe option as we don't have too much tasks anymore in the backlog.