Closed
Bug 419487
Opened 17 years ago
Closed 17 years ago
change buildbot & talos to use buildtime, not test-run time
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: joduinn, Assigned: anodelman)
References
Details
(Whiteboard: needs scheduled downtime)
Attachments
(2 files, 1 obsolete file)
8.45 KB,
patch
|
rcampbell
:
review+
|
Details | Diff | Splinter Review |
4.25 KB,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
Reporter | ||
Comment 1•17 years ago
|
||
There is no change needed to graph server. We just need to change buildbot & talos to pass buildtime instead of test-runtime.
Summary: change graph server to display buildtime, not test-run time → change buildbot & talos to use buildtime, not test-run time
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → anodelman
Assignee | ||
Updated•17 years ago
|
Component: Build & Release → Release Engineering
Priority: -- → P3
Updated•17 years ago
|
QA Contact: build → release
Assignee | ||
Comment 2•17 years ago
|
||
Attachment #318698 -
Flags: review?(rcampbell)
Assignee | ||
Comment 3•17 years ago
|
||
Add support to PerfConfigurator:
- pull buildid from application.ini of talos
- use a testdate as an argument for timestamping the results
- have the option of using the buildid as a timestamp (might still be useful for baseline work)
- handle dates that are either 10 digits or 12 digits long (YmdH or YmdHM)
Attachment #318699 -
Flags: review?(rcampbell)
Assignee | ||
Comment 4•17 years ago
|
||
Currently talos reports results to the graph server timestamped with test start time. This makes it hard to determine regression ranges as the test time has no connection to when the build being tested was created.
If we go with this solution the talos machines will start to use timestamps that reflect the build start time as used on the waterfall - so talos results would line up with waterfall results.
This should make it easier to track regressions and determine bonsai ranges for a given test.
We would _not_ be using the BuildID as stored in the application.ini for timestamping, it would just be stored in the graph server database as an extra piece of information.
Priority: P3 → P2
Updated•17 years ago
|
Attachment #318698 -
Flags: review?(rcampbell) → review+
Comment 5•17 years ago
|
||
Comment on attachment 318699 [details] [diff] [review]
patches PerfConfigurator to handle new timestamp format
this seems to work ok on mac. I wish the error-handling were a bit better and more informative, but that's probably worth filing another bug to fix it.
Attachment #318699 -
Flags: review?(rcampbell) → review+
Assignee | ||
Comment 6•17 years ago
|
||
Adding a dependency to bug 291167 - there's no point in changing the time stamp to buildtime until we can guarantee that we are pulling the correct build.
Depends on: 291167
Reporter | ||
Updated•17 years ago
|
Whiteboard: needs scheduled downtime
Comment 7•17 years ago
|
||
+1 to this change if it happens after FF3 release, with a little bit of advance notice in the newsgroups as to when the actual "flag day" will be.
It will absolutely make it easier to track down regressions in the future, especially now that we have multiple boxes reporting, so that we can play off near-adjacent machines against each other to build a small check-in window.
Probably want to do this on a day that the tree's been green (well, perf-flat, I guess I mean) for a solid 24 hours or so, so that we're unlikely to be looking for regressions across the jump.
Assignee | ||
Comment 8•17 years ago
|
||
Adding blocking on bug 388685 (graph server should handle duplicate data better). If we switch to using build time there is a not entirely unlikely situation where we would end up serving the same build to a single machine to test twice - resulting in an attempt to send data with the same time stamp to the graph server and thus corrupting the graph server database.
The simplest solution as I see it would be to have the graph server simply delete any previous data collected for a machine/timestamp key and replace it with the new data. In future we'd like to collect the information in a more sensible manner, but this would get us where we want to be for now.
Assignee | ||
Comment 9•17 years ago
|
||
We now have a system in place for dealing with duplicate data in the graph server (the bug remains open waiting for a check in to hg). We are also in a slow(ish) state after ff3 - this is probably the best time that we are going to get to land this and see what sort of fall out there is.
Next scheduled outage we should include this patch. It should only be pushed when all trees are closed.
Assignee | ||
Comment 10•17 years ago
|
||
Missed out on the change to talos try. Should push all of this at the same time for things to not go red.
Attachment #318698 -
Attachment is obsolete: true
Attachment #326584 -
Flags: review?(bhearsum)
Updated•17 years ago
|
Attachment #326584 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 11•17 years ago
|
||
talos change:
Checking in PerfConfigurator.py;
/cvsroot/mozilla/testing/performance/talos/PerfConfigurator.py,v <-- PerfConfigurator.py
new revision: 1.4; previous revision: 1.3
done
buildbot changes:
Checking in perfmaster/perfrunner.py;
/cvsroot/mozilla/tools/buildbot-configs/testing/talos/perfmaster/perfrunner.py,v <-- perfrunner.py
new revision: 1.18; previous revision: 1.17
done
Checking in tryperfmaster/perfrunner.py;
/cvsroot/mozilla/tools/buildbot-configs/testing/talos/tryperfmaster/perfrunner.py,v <-- perfrunner.py
new revision: 1.4; previous revision: 1.3
done
Assignee | ||
Comment 12•17 years ago
|
||
Filed bug 441837 for bustage after pushing patches.
Assignee | ||
Comment 13•17 years ago
|
||
This is up and working correctly on production.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•