When I deployed the new dev instance of taskotron, I found out that resultsdb doesn't behave well when proxied.
For example, the request: curl http://taskotron-dev.fedoraproject.org/resultsdb/resultsdb/api/v1.0/jobs
yeilds:
... { "end_time": "2014-07-04T02:47:25.132483", "href": "http://resultsdb-dev01.qa.fedoraproject.org/resultsdb/api/v1.0/jobs/1", "id": 1, "name": "rpmlint", "ref_url": "http://taskotron-dev.fedoraproject.org/taskmaster//builders/x86_64/builds/27", "results": null, "results_count": 1, "start_time": "2014-07-04T02:47:25.071434", "status": "COMPLETED" } ], "href": "http://taskotron-dev.fedoraproject.org/resultsdb/api/v1.0/jobs", "next": "http://taskotron-dev.fedoraproject.org/resultsdb/api/v1.0/jobs?page=1", "prev": null
Note the incorrect url for href and next. Similar to #276, this isn't the exact proxying configuration which will end up on stg and prod but there's no reason to think that the same thing won't show up when proxied at a different URL. This doesn't directly affect deploy-ability of Taskotron so it's not as high of a priority as #276.
href
next
One solution (and the one that [[https://github.com/fedora-infra/fedocal/blob/master/fedocal/proxy.py|fedocal]] uses) is outlined as a [[http://flask.pocoo.org/snippets/35/|flask snippet]].
Fix resultsdb such that it uses correct urls when behind a reverse proxy.
This ticket had assigned some Differential requests: D185
Closed by commit rRSDBd05c620ce8d7.
Login to comment on this ticket.