Description of problem: Need a report of a number of jobs that's priority has changed by admin Description: When a job is in a queue for a long time, sometimes business critiical situation occurs and the job priority has to be changed manually by admin. Motivation: The number of job priority change will help the manager to analyse project retrospect and contribute to the better planning for the next release.
I think it might be best to monitor this via graphite or something.
(In reply to comment #1) > I think it might be best to monitor this via graphite or something. A monitoring loop could be used for such a thing. When the priority changes, the carbon daemon is sent the corresponding change. However, that is probably for real time stats. For archiving purpose and hence enable report generation, these changes need also be mined from the existing tables or stored in a new one..
I think we can use the data stored in tables recipeset_activity and activity to create a report of these priority changes. Every time the priority is changed, an activity of type "recipeset_activity", action "changed" for the "Priority" field is recorded in the activity table. Using this along with recipeset_activity table, we can create reports of recipeset priority changes and hence job priority changes. I noticed that when the job's priority is changed, one activity of the above type is generated for each recipeset.
(In reply to comment #3) > I think we can use the data stored in tables recipeset_activity and activity > to create a report of these priority changes. > > Every time the priority is changed, an activity of type > "recipeset_activity", action "changed" for the "Priority" field is recorded > in the activity table. Using this along with recipeset_activity table, we > can create reports of recipeset priority changes and hence job priority > changes. > > I noticed that when the job's priority is changed, one activity of the above > type is generated for each recipeset. Right, normally that would make sense. However the RFE is not really a requirement of beaker itself, it's a reporting requirement that would have little to no value outside of red hat I would imagine. If we were to create such a table, I can't think of anything else that we would want to put in there, and, as far as I understand it, the motivation for it would only require it to be temporary, thus after a release or two it would become more or less useless to us. Of course perhaps I don't understand the requirement and motivation as well as I think, and being able to forever see within beaker how often priorities are being raised might be useful?
(In reply to comment #3) > I think we can use the data stored in tables recipeset_activity and activity > to create a report of these priority changes. > > Every time the priority is changed, an activity of type > "recipeset_activity", action "changed" for the "Priority" field is recorded > in the activity table. Using this along with recipeset_activity table, we > can create reports of recipeset priority changes and hence job priority > changes. > > I noticed that when the job's priority is changed, one activity of the above > type is generated for each recipeset. Ugh...you are of course completely right. I didn't double check this before I told Min we did not record this, how lazy of me.
Ok so after talking further with Min, it seems we want to be able to actually generate reports.
For all of these reporting requirements, they can be closed with a documented SQL query describing how to extract the relevant events from our database schema. Actually *displaying* the data can then be offloaded to an external reporting tool like Jasper Reports. This means integrated displays are a nice-to-have rather than a hard requirement.
SELECT tg_user.user_name, count(tg_user.user_name) AS number_of_jobs_changed FROM (SELECT activity.user_id as user_id FROM activity INNER JOIN recipeset_activity ON recipeset_activity.id = activity.id INNER JOIN recipe_set ON recipe_set.id = recipeset_activity.recipeset_id INNER JOIN job ON job.id = recipe_set.job_id WHERE MONTHNAME(activity.created) IN ('July', 'August') AND new_value IN ('High', 'Urgent') AND old_value != new_value GROUP BY job.id) AS a LEFT JOIN tg_user ON tg_user.user_id = a.user_id GROUP BY tg_user.user_name; Change the months 'July', 'August' to whatever months are applicable. This query assumes that one person is responsible for each priority bump within a job (which is most likely)
I think we're just after the total number of priority changes (i.e. "admin" as a collective term, rather than referring to individuals) Also adding the dependency on the ability to link out to an external reporting system.
(In reply to comment #0) > Description of problem: > > Need a report of a number of jobs that's priority has changed by admin > > Description: When a job is in a queue for a long time, sometimes business > critiical situation occurs and the job priority has to be changed manually > by admin. I think we should also consider how long did the job spend in the "processed" state before its priority was bumped. > > Motivation: The number of job priority change will help the manager to > analyse project retrospect and contribute to the better planning for the > next release.
Re-opening since this will need to be added to the queries in Server/bkr/server/reporting-queries with a test.
http://gerrit.beaker-project.org/#/c/1589/
Beaker 0.11.0 has been released.