610286 - link to JSON and full logs

Status: RESOLVED FIXED

(Tree Management Graveyard :: OrangeFactor, defect, P1)

Description

[Jeff Hammel]

links to the JSON summaries and full logs should be presented whereever applicable

Comment 1

[Jeff Hammel]

this is probably dependent on getting the logs in the new db

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

we could just link the tinderbox log for the time being.  I don't want to assume we will have log servers up and running anytime soon.

Comment 4

[Jonathan Griffin (:jgriffin)]

We really need two kinds of data:

1 - a high-level summary of failures, shown as a popup or something in views such as http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=452706&startday=2011-01-03&endday=2011-01-28

This data can be retrieved from ES; see raw data at e.g.,
http://elasticsearch1.metrics.sjc1.mozilla.com:9200/logs/testfailures/_search?q=date:2011-02-04&size=50

2 - we should provide a link to the full log on stage (not tinderbox); stage has been upgraded and should be storing 30 days of logs now, and tinderbox will eventually be going away; we can figure out this link using an ES query

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

so would you advocate 2 additional links near the top of the Bug Details page:
[raw data] [raw log] ?

Another thing is the data from elasticsearch is not accessible via the normal internet.  Should we maybe make something like this:
http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=452706&startday=2011-01-03&endday=2011-01-28&output=json ?

^ not a real link, just an idea to add a output param to the url.

I think we could make that a new window/popup/tab or something like that.

Comment 6

[Jonathan Griffin (:jgriffin)]

We'll need links for each instance of the bug, rather than links at the top of the page, since each instance has a unique log file and potentially a unique signature.

I was thinking we could put the links in the bug table.

I'll add a new query to woo_server.py that will return this info; when the user clicks the 'summary' link (or whatever we're going to call it), we can get the data via the REST API, and then display it in a popup div (similar to the way tbpl presents testrun data).

For the log file link, I'll just update the existing queries in woo_server.py so that they return this info in addition to other details.

Comment 7

[Jonathan Griffin (:jgriffin)]

Attachment: woo_server.py patch

This patch adds a new 'testrun' view to woo_server.  With the starttime and machine name from a given orange (see bug 619505), you can use this to request all the testrun metadata that ElasticSearch has for that testrun.  The output is a list of testruns with a bunch of fields as described in the bug; I'm also attaching some example output for easier review.

Comment 8

[Jonathan Griffin (:jgriffin)]

Attachment: example testrun output from woo_server patch

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

Comment on attachment 510418 [details] [diff] [review]
woo_server.py patch

nice!

Comment 10

[Jonathan Griffin (:jgriffin)]

The 'logurl' backend code is now live, so the 'logurl' can now be retrieved using the new 'testrun' query, e.g.:

http://brasstacks.mozilla.com/orangefactor/testrun?starttime=1297306345&machine=talos-r3-snow-050

Comment 11

[Jonathan Griffin (:jgriffin)]

Attachment: patch to support multiple test runs in a single request

Per mcote's request, an udpate to the serve_testrun that can work with multiple testruns so you don't need to make a separate XHR for each testrun.  The resulting JSON is indexed by 'starttime|machine', e.g., 

{
  '1295484366|talos-r3-xp-037' : [ testrun list ],
  '1297070365|talos-r3-leopard-012' : [ testrun list ]
}

Comment 12

[Mark Côté [:mcote]]

Comment on attachment 512641 [details] [diff] [review]
patch to support multiple test runs in a single request

Nice.  Great to see some proper Python from someone. ;)

+            runparams = run.split('|')
+            if len(runparams) == 2:
+              starttime = runparams[0]
+              machine = runparams[1]

This is perfectly fine, but did you know about string.partition()?  I myself only found out about it recently.  You can replace those four lines with

starttime, sep, machine = runparams.partition('|')
if sep != '':

Just thought you might be interested to know.

Anyway great stuff.

Comment 13

[Jonathan Griffin (:jgriffin)]

> Comment on attachment 512641 [details] [diff] [review]
> patch to support multiple test runs in a single request
> > 
> +            runparams = run.split('|')
> +            if len(runparams) == 2:
> +              starttime = runparams[0]
> +              machine = runparams[1]
> 
> This is perfectly fine, but did you know about string.partition()?  I myself
> only found out about it recently.  You can replace those four lines with
> 
> starttime, sep, machine = runparams.partition('|')
> if sep != '':
> 
> Just thought you might be interested to know.

Sweet!  I ran into partition once, then promptly forgot about it.  Thanks for reminding me.

Patch (with update) pushed as http://hg.mozilla.org/automation/orangefactor/rev/270de78edb0f

Comment 14

[Mark Côté [:mcote]]

Attachment: Links to JSON and logs on Bug Details page

Hokay, so this patch grabs testrun data and inserts links to the full log and to the raw JSON, if available.  The JSON is displayed in a sliding popup.  Not much else to say here.

Comment 15

[Jonathan Griffin (:jgriffin)]

Comment on attachment 513252 [details] [diff] [review]
Links to JSON and logs on Bug Details page

Looks great!  

What do you think about 1em instead of 0.75em font-size for #popup p?  0.75em makes it almost unreadably small on my machine.

Comment 16

[Mark Côté [:mcote]]

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/9449a4861480

I think that's it for this bug.

Comment 17

[Mark Côté [:mcote]]

Oops forgot to change the font size.  Increased to 1em.

http://hg.mozilla.org/automation/orangefactor/rev/9b04a885a4eb