Closed Bug 713444 Opened 13 years ago Closed 12 years ago

Graph server API seems to be broken, breaking compare-talos

Categories

(Webtools Graveyard :: Graph Server, defect)

x86
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzbarsky, Unassigned)

Details

As far as I can tell, compare-talos uses an XHR get of a URI like http://graphs.mozilla.org/api/test/runs/revisions?revision=4e5e4aa72752&revision=146f2c7559d4 to get the data it looks at.

Sadly, that URI gives an internal server error right now, which makes compare-talos not work.

This is actually sort of blocking some work on my end.
Assignee: nobody → server-ops
Component: Graph Server → Server Operations
Product: Webtools → mozilla.org
QA Contact: graph.server → cshields
Version: Trunk → other
I see this in the error log:

[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210] mod_wsgi (pid=15635): Exception occurred processing WSGI script '/var/www/html/graphs/server/api.wsgi'.
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210] Traceback (most recent call last):
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]   File "/usr/lib/python2.6/site-packages/WebOb-1.0.7-py2.6.egg/webob/dec.py", line 147, in __call__
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]     resp = self.call_func(req, *args, **self.kwargs)
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]   File "/usr/lib/python2.6/site-packages/WebOb-1.0.7-py2.6.egg/webob/dec.py", line 208, in call_func
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]     return self.func(req, *args, **kwargs)
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]   File "/var/www/html/graphs/server/api_cgi.py", line 71, in application
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]     result = options[item](id, attribute, req)
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]   File "/var/www/html/graphs/server/api.py", line 329, in getTestRun
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]     return getRevisionValues(req)
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]   File "/var/www/html/graphs/server/api.py", line 507, in getRevisionValues
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210]     for row in cursor:
[Sun Dec 25 09:23:49 2011] [error] [client 10.2.74.210] TypeError: 'RetryCursor' object is not iterable

Looks like a code issue.
Assignee: server-ops → nobody
Component: Server Operations → Graph Server
Product: mozilla.org → Webtools
QA Contact: cshields → graph.server
The problem is that the new graph server uses a slightly different API, and graphs.m.o now points to the new graphserver per bug 698989. The old URL is blocked.

However, the old one is still available via graphs-old.mozilla.org so the quick fix is to point compare-talos to:

http://graphs.mozilla.org/api/test

We tried to find and move all of these before hand, but obviously missed this one. Sorry about that!

When we have time, compare-talos should be move to http://graphs.mozilla.org/api/test?attribute=short

Who runs compare-talos? Can this easily be changed to graphs-old?

Dumitru, maybe we should put a redirect in to graphs-old (instead of the "deny" that's in there now).
(In reply to Robert Helmer [:rhelmer] from comment #2)
> The problem is that the new graph server uses a slightly different API, and
> graphs.m.o now points to the new graphserver per bug 698989. The old URL is
> blocked.
> 
> However, the old one is still available via graphs-old.mozilla.org so the
> quick fix is to point compare-talos to:
> 
> http://graphs.mozilla.org/api/test

I mean to say: http://graphs-old.mozilla.org/api/test
>  Can this easily be changed to graphs-old?

The source is at https://bitbucket.org/mconnor/compare-talos

Not sure what deployment involves...
(In reply to Boris Zbarsky (:bz) from comment #4)
> Not sure what deployment involves...

Two things: creating https://bitbucket.org/mconnor/compare-talos/pull-request/2/update-graphserver-url-to-graphs-oldmo and then mconnor pulling it and updating his copy on snarkfest.
Fixed in bug 741477 (missed this bug somehow when resolving!)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.