Bug 877272

Summary:	Task execution time and history per arch
Product:	[Retired] Beaker	Reporter:	Min Shin <mishin>
Component:	reports	Assignee:	Dan Callaghan <dcallagh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nick Coghlan <ncoghlan>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	0.9	CC:	asaha, dcallagh, llim, mishin, rglasz, rmancy
Target Milestone:	0.11	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Measurements
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-17 04:34:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Min Shin 2012-11-16 06:02:20 UTC

Description of problem:

Need to have metrics on task execution time and history per arch to determine total recipe effectiveness. e.g. time used by tasks itself / overall recipe time.

Example: A machine's time is solely taken up by running tasks. Machines that are pre-occupied by running small number of tasks for a very long amount of time are probably more indicitive of resource abuse than large number of tasks run for small amounts of time. Save this data per arch so that graph can be shown together with min, max and median. Counting should not include harness overhead.  

Motivation: Admin wants to find tasks which run for 'extreme' lengths of time and investigate as to their proportion of overall machines time and whether we need to place limits on these. Users want see how efficiantly their tasks are so that they can schedule long tasks as last in recipes, can notice significant execution time change in time and search for reasons.

Comment 1 Min Shin 2012-11-22 03:25:01 UTC

ncoghlan: probably not too hard to do, since we'll likely be building up the machine level metrics from task level metrics

Comment 2 Nick Coghlan 2012-12-05 02:03:54 UTC

Amit, another one where the main question is whether or not we're already recording the required data in the DB.

Comment 3 Amit Saha 2012-12-06 05:48:19 UTC

Using the data from the distro, distro_tree, recipe_task, recipe_resource, task, arch tables, it is possible to retrieve the data per arch and system:

mysql> select task.name,recipe_resource.fqdn, arch.arch,task.avg_time,timediff(recipe_task.finish_time,recipe_task.start_time)  from distro, distro_tree,recipe,recipe_task,task,arch,recipe_resource where recipe_task.task_id=task.id and recipe.id=recipe_task.recipe_id and recipe.distro_tree_id=distro_tree.id and arch.id=distro_tree.arch_id and recipe_resource.recipe_id=recipe_task.recipe_id order by task.name;

Returns sample data such as:

| /installation/mytask/Sanity/ext4-test | virt-10   | x86_64 |      300 | 01:12:35                                                 | 
| /installation/mytask/Sanity/ext4-test | virt-12   | x86_64 |      300 | 00:08:22   

The per system/arch data can then be aggregated and inferences drawn from them.

The recorded time does however include the installation of the task RPM. I am not sure if we have any data that is recorded exclusively for the duration during which the task is executing.

Comment 4 Dan Callaghan 2012-12-06 21:54:49 UTC

(In reply to comment #3)

This works except for the first task in each recipe (usually but not necessarily /distribution/install) which will include installation time. I think this report will need to filter those out.

Comment 5 Amit Saha 2012-12-07 00:13:33 UTC

(In reply to comment #4)
> (In reply to comment #3)
> 
> This works except for the first task in each recipe (usually but not
> necessarily /distribution/install) which will include installation time. I
> think this report will need to filter those out.

Right. The initial report that gets generated will have all these tasks. It is probably a fair assumption that those who will look at the reports are well informed users and hence they can either choose to ignore /distribution/install or such tasks or specify tasks that they don't want to see and the report can be regenerated the data *without* making any further database queries. 

Hence, the implementation can fetch the data for all tasks when the report is generated and regenerate the graphs/reports as per user's preferences. The latter would be a secondary requirement, if its not to difficult to implement in the reporting environment.

Comment 6 Amit Saha 2012-12-11 07:56:35 UTC

Admin guide updated to include the above information: http://gerrit.beaker-project.org/#/c/1546/

Comment 7 Dan Callaghan 2012-12-17 08:46:02 UTC

http://gerrit.beaker-project.org/1576

Comment 8 Nick Coghlan 2013-01-10 06:09:43 UTC

Another case that needs to use a subquery in order to work in more SQL dialects.

Comment 9 Dan Callaghan 2013-01-10 07:19:50 UTC

http://gerrit.beaker-project.org/1630

Comment 10 Nick Coghlan 2013-01-10 07:51:11 UTC

Latest version also works in Teiid with the standard MySQL -> Teiid conversions of adding the SQL_TSI_ prefix and replacing the date/time strings with explicit PARSETIMESTAMP calls.

Comment 11 Dan Callaghan 2013-01-17 04:34:44 UTC

Beaker 0.11.0 has been released.