Bug 1291130 - [RFE] provide a stable "bouncer" URL for job logs, which always redirects to the current storage location
[RFE] provide a stable "bouncer" URL for job logs, which always redirects to ...
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: general (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified (vote)
: 22.0
: ---
Assigned To: Dan Callaghan
tools-bugs
: FutureFeature, Patch, Triaged
Depends On:
Blocks: 915319
  Show dependency treegraph
 
Reported: 2015-12-13 23:34 EST by Dan Callaghan
Modified: 2016-01-14 00:33 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-14 00:33:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Callaghan 2015-12-13 23:34:11 EST
In Beaker sites which are using beaker-transfer with an archive server (like Red Hat's production Beaker deployment) job logs live on the lab controller while the job is running, and for a short time afterwards, but then they are moved to the archive server by beaker-transfer. At that point all the URLs change.

Beaker always knows what the current location for the logs is. But there are still some situations where we link someone to the logs stored on the lab controller but by the time they click the link, it is invalid and the logs are stored on the archive server instead.

One example is a human opening the job page while the job is still running, leaving it alone for a few minutes (during which time beaker-transfer moves the logs) and then clicking on one of the logs. At that point they will see a 404 message (albeit with a hint about why, due to bug 811241).

Another scenario is a script which uses bkr job-watch to wait the end of a job, followed by bkr job-logs to immediately fetch the log files, or bkr job-results --format=junit-xml to fetch JUnit XML with log URLs. Most likely Beaker will return the lab controller URLs for the logs but shortly aftewards the URLs will become invalid when the logs are moved.

Instead of linking to the logs at their current storage location, we could provide new URLs which will always return a 307 Temporary Redirect to the current storage location. Then every place where we provide a link to the logs (job results in the web UI, taskactions.logs XMLRPC call, JUnit XML results, and in future Beaker job results XML) we would use this "bouncer" URL instead. That ensures if the log storage moves in future the links won't break.

There are endpoints already defined in the lab controller API which we could re-use on the server side:

GET /recipes/(recipe_id)/logs/(path: path)
GET /recipes/(recipe_id)/tasks/(task_id)/logs/(path: path)
GET /recipes/(recipe_id)/tasks/(task_id)/results/(result_id)/logs/(path: path)
Comment 1 Dan Callaghan 2015-12-14 18:59:43 EST
I would like to get this into 22.0 since it's necessary to make the JUnit XML output actually usable.
Comment 2 Dan Callaghan 2015-12-14 20:49:11 EST
http://gerrit.beaker-project.org/4542
Comment 5 Dan Callaghan 2016-01-14 00:33:32 EST
Beaker 22.0 has been released.

Note You need to log in before you can comment on or make changes to this bug.