coordination #32851
closed
[tools][EPIC] Scheduling redesign
Added by EDiGiacinto about 6 years ago.
Updated over 3 years ago.
Category:
Feature requests
Estimated time:
(Total: 0.00 h)
Description
Currently we are scheduling using DB with specific crafted query with the ORM - which is a consuming process both in terms of CPU and memory, even refining furthermore the query could be in long-term a dead end, and being problematic as we might have more requirements from it.
This ticket is meant just as a tracker to group refactorization/enhancements, redesign proposals.
My 2c With regards to replacing DB, and doing it in memory - if AMQP is not a way to go (so, that means also dispatching jobs over ws would be replaced) - i would explore the possibility to switch to a SAT solving mechanism instead, avoiding to hard-code condition ourselves in the future. As i see it, we can re-formulate our problem as conditions that can be nicely expressed in CNF.
Don't! The problem is way too simple for such a monster solution
- Related to action #20812: Jobs will be assigned to workers with wrong arch unless WORKER_CLASS is set somewhere added
- Related to action #25970: Profile/Optimize _workers_checker in WebSockets server added
- Related to action #28714: [tools] Investigate why sporadically job is set to scalar value of the reference instead of the reference itself. added
coolo wrote:
Don't! The problem is way too simple for such a monster solution
Well, it seems growing in complexity now, so maybe a simple solution is not enough anymore - and it might actually help slim the logic, as we could infer CNFs from job settings.
Not saying that is the road to hit - just worth mentioning the possibilities.
- Related to action #31069: Job life cycle not always covered by events added
- Related to action #25124: [tools][sprint 201709.1] Workers disconnects from websocket server and getting stuck: job shows as 'State: assigned' forever added
- Related to action #35296: Error messages on worker about "Use of uninitialized value $host in hash element at /usr/share/openqa/script/../lib/OpenQA/Worker/Common.pm line 359, <GEN298662> line 4." added
- Due date set to 2018-05-05
due to changes in a related task
- Related to action #36727: job_grab does not cope with parallel cycles added
- Category changed from 122 to Feature requests
- Status changed from New to Resolved
- Assignee set to okurz
The one open subtask #12876 is still a valid feature request but I doubt we need this top-level tracker as it does not provide more details.
- Tracker changed from action to coordination
Also available in: Atom
PDF