action #6564
closed(re-)add Job::worker_id
0%
Description
It would be good to display in the job which worker ran the job (especially if it misbehaved). For this it would be good not to reset $job->worker when it's done.
As we have many places where the existance of $job->worker marks a running job, we would need to add a job_id to the worker table, so we can check for $job->worker->job == $job I guess.
Updated by okurz over 8 years ago
- Assignee set to coolo
I assume this is done with commit ddb4f70c1951068624c59e9cfd635bc5c9708c13
Author: Stephan Kulow coolo@suse.de
Date: Wed Jun 8 06:48:56 2016 +0200
Move Jobs::worker_id to Worker::job_id
And add unique constraint to the job_id in the workers table (which is
much smaller)
?
please close if done.
Updated by coolo over 8 years ago
- Subject changed from redeclare Job::worker_id to (re-)add Job::worker_id
- Assignee deleted (
coolo)
It's not. But it's prepared now as there is no Job::worker_id anymore with a meaning - now we can freely add it to be displayed.
When you fix the t_finished of cancelled jobs, you can add that too.
Updated by coolo over 8 years ago
- Blocks action #13144: show history of jobs in worker view added
Updated by okurz about 8 years ago
- Blocks action #14902: [tools]incomplete job with no log file -> uploading failed in autoinst-log.txt added
Updated by okurz about 8 years ago
- Related to action #13952: too many warnings about dead workers in log added
Updated by mkittler about 8 years ago
- Related to action #15386: Continue job already considered dead added
Updated by mkittler about 8 years ago
- Status changed from New to Feedback
- Assignee set to mkittler
Not sure whether it makes sense to store the worker ID. When checking the test results the worker might have already been deleted from the workers table and maybe re-added under another ID. So it would make more sense to store the actual string to be displayed, eg. 'g182:1'. I would call the column last_assigned_worker to avoid confusion with the relation which is already present.
Updated by coolo about 8 years ago
I see the point of avoiding an ID, but if you delete a worker from the table then all the jobs associated with it loose the information. I don't know anything about g182:1 anyway. Having an id makes sure we can link to it directly instead of mapping it. But I don't mind either.
What I do mind though is the last_ prefix - either there is a worker accociated to the job or there is not. But there is no last one.
Updated by mkittler about 8 years ago
but if you delete a worker from the table then all the jobs associated with it loose the information.
That is exactly what I'm trying to avoid.
I don't know anything about g182:1 anyway.
'g182:1' was just an example taken from my local instance.
Having an id makes sure we can link to it directly instead of mapping it.
Do you have another use-case in mind which would require more information about the worker than we would store in the string? If yes, the required mapping would be worse option I guess.
either there is a worker accociated to the job or there is not
So I'll call it just associated_worker. (Some prefix is required to distinguish from already existing worker.)
Updated by mkittler about 8 years ago
- Status changed from Feedback to In Progress
PR: https://github.com/os-autoinst/openQA/pull/1079
Decided to store IDs now instead of strings because of #13144.
EDIT (okurz): Please reference tickets with #<nr> to make it proper links with hover information.
Updated by mkittler almost 8 years ago
- Status changed from In Progress to Resolved
Merged and works in production: https://openqa.suse.de/tests/677617