log the time db patch application takes in developer accessible location

Bug #678289 reported by Robert Collins
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Stuart Bishop

Bug Description

I realise that this is /very close/ to being a duplicate, but I wanted a single clear statement of what we need.

We need to record somewhere where developers can access it, how long each DB patch takes to apply. Recording in a log file that is rsynced to devpad would be fine.

This is important (e.g. before the release in december) because we need this to QA db patches as part of continuous deployment; moving to an incremental fashion there matters because its a prerequisite for safely merging db-devel to devel pre-release - and that matters because the qa toolchain functions better if we keep just one branch deployed.

summary: - log in developer accessible location the time db patch application takes
+ log the time db patch application takes in developer accessible location
Revision history for this message
Gary Poster (gary) wrote :

I think Robert is talking about bug 368600, which Stuart closed as Won't Fix. I like this proposed change.

Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Stuart Bishop (stub) wrote :

I've added the patch timings to security.py output, code currently in review.

Once this lands, developers can see the output buried in /srv/launchpad.net-logs/staging/sourcherry/[...]-staging-restore.log

To make this more accessible, we can update the staging update script to run upgrade.py using an argument like the following to spool its output separately:

./upgrade.py --log-file=INFO:/srv/staging-logs/dbupgrade.log

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 678289] Re: log the time db patch application takes in developer accessible location

\o/

Revision history for this message
Launchpad QA Bot (lpqabot) wrote : Bug fixed by a commit
Changed in launchpad-foundations:
assignee: nobody → Stuart Bishop (stub)
milestone: none → 10.12
tags: added: qa-needstesting
Changed in launchpad-foundations:
status: Triaged → Fix Committed
Revision history for this message
Gary Poster (gary) wrote :

Could Stuart or a LOSA ack that the message to use ``./upgrade.py --log-file=INFO:/srv/staging-logs/dbupgrade.log`` has been successfully passed on to the LOSAs? I'd be happy to send an RT if it had not been done yet.

Aaron Bentley (abentley)
tags: added: bad-commit-9997
removed: qa-needstesting
tags: added: qa-bad
tags: removed: qa-bad
Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Revision history for this message
Stuart Bishop (stub) wrote :

For Gary's request on logging the information to a separate log file,

Full rebuild logging to the dbupgrade.log is at https://code.launchpad.net/~stub/launchpad/pending-db-changes/+merge/44198

Upgrade only update is at https://code.launchpad.net/~stub/lp-staging-scripts/devel/+merge/44200

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
Changed in launchpad:
milestone: 10.12 → none
Stuart Bishop (stub)
tags: added: qa-ok
removed: qa-needstesting
Changed in launchpad:
status: Fix Committed → Fix Released
Curtis Hovey (sinzui)
Changed in launchpad:
milestone: none → 11.01
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.