| 2010-12-09 15:05:54 |
Aaron Bentley |
bug |
|
|
added bug |
| 2011-01-12 04:08:49 |
Robert Collins |
summary |
Deployment reports are not updated if qastaging is down |
when qastaging is down deployment reports crash and stop updating |
|
| 2011-01-12 04:09:46 |
Robert Collins |
description |
qa-tagger appears to require qastaging to be running in order to determine which revno is deployed. This prevents the deployment report from being updated, even though other elements of that report may have changed (i.e. bug tags changing).
The deployment report is the best place to monitor QA status, so the release manager's job becomes harder when the report stops updating. It would be better to use the last deployed revno when the current deployed revno cannot be determined. |
qa-tagger requires staging and qastaging to be running in order to determine which revno is deployed.
When this fails no fallback is present and the reports simply stop.
The deployment report is the best place to monitor QA status, so the release manager's job becomes harder when the report stops updating.
One possible fix would be to cache the last seen revnos and use those when the system cannot be queried (and show that it could not be queried in the UI).
|
|
| 2011-01-12 04:09:50 |
Robert Collins |
qa-tagger: status |
New |
Triaged |
|
| 2011-01-12 04:09:53 |
Robert Collins |
qa-tagger: importance |
Undecided |
High |
|
| 2012-01-07 04:24:45 |
Robert Collins |
description |
qa-tagger requires staging and qastaging to be running in order to determine which revno is deployed.
When this fails no fallback is present and the reports simply stop.
The deployment report is the best place to monitor QA status, so the release manager's job becomes harder when the report stops updating.
One possible fix would be to cache the last seen revnos and use those when the system cannot be queried (and show that it could not be queried in the UI).
|
qa-tagger requires staging and qastaging to be running in order to determine which revno is deployed.
When this fails no fallback is present and the reports simply stop.
The deployment report is the best place to monitor QA status, so the release manager's job becomes harder when the report stops updating.
Solutions
=========
One possible fix would be to cache the last seen revnos and use those when the system cannot be queried (and show that it could not be queried in the UI).
Don't delete the old report if the new one fails to render. |
|
| 2012-01-07 04:24:52 |
Robert Collins |
tags |
|
easy |
|
