| 2010-03-04 10:56:05 |
Tom Haddon |
bug |
|
|
added bug |
| 2010-03-04 10:56:18 |
Tom Haddon |
launchpad: importance |
Undecided |
High |
|
| 2010-03-04 10:56:37 |
Tom Haddon |
removed subscriber Tom Haddon |
|
|
|
| 2010-03-04 13:48:08 |
Brad Crittenden |
affects |
launchpad |
launchpad-foundations |
|
| 2010-03-04 13:49:35 |
Brad Crittenden |
launchpad-foundations: status |
New |
Triaged |
|
| 2010-03-04 15:56:22 |
Francis J. Lacoste |
launchpad-foundations: status |
Triaged |
New |
|
| 2010-03-04 15:56:36 |
Francis J. Lacoste |
launchpad-foundations: status |
New |
Triaged |
|
| 2010-03-04 16:52:27 |
Gary Poster |
launchpad-foundations: milestone |
|
10.03 |
|
| 2010-03-04 17:16:01 |
Tom Haddon |
summary |
Need more visibility into the progress of upgrade.py/fti.py/security.py |
Need more visibility into the progress of schema updates across master and slave DBs |
|
| 2010-03-04 17:17:37 |
Tom Haddon |
description |
Each LP rollout at the moment is something of a lottery in terms of timing. Since figuring out whether any of the upgrade.py/fti.py/security.py steps are being blocked in some way is non-trivial, it's hard for us to know when things are going wrong. If we've estimated that the upgrade should take 30 mins, we only really start to worry if things have gone wrong in some way after about 35 minutes. If we're still only 20% of the way through at that stage, our outage estimations are going to be completely wrong.
Ideally we'd have:
- Some kind of percentage progress bar
- Some easily visible and unmistakeable indication if the process is blocked in any way, and what to do about it |
Each LP rollout at the moment is something of a lottery in terms of timing. Since figuring out whether any of the upgrade.py/fti.py/security.py steps are being blocked in some way is non-trivial, it's hard for us to know when things are going wrong. If we've estimated that the upgrade should take 30 mins, we only really start to worry if things have gone wrong in some way after about 35 minutes. If we're still only 20% of the way through at that stage, our outage estimations are going to be completely wrong.
Ideally we'd have some easy way of determining the progress of updates against the master and each slave DB, and whether they're being blocked in any way.
It would also be useful for the more general case of knowing what's happening on slave DBs to be able to see what the queue of items they're waiting to process is and whether they're blocked in any way.
|
|
| 2010-03-23 22:08:01 |
Gary Poster |
launchpad-foundations: milestone |
10.03 |
|
|
| 2010-03-30 11:22:27 |
Stuart Bishop |
launchpad-foundations: assignee |
|
Stuart Bishop (stub) |
|
| 2010-04-01 14:12:08 |
Stuart Bishop |
launchpad-foundations: status |
Triaged |
Won't Fix |
|
