The copy-translations-from-parent script should really be restartable.

Bug #778430 reported by Henning Eggers
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Although this script was the problem at hand, dealing with long-running translations might be the real problem.

The script claims to be restartable but is it really?

[09:13] <danilo> henninge, we will have to remove data that it has created so far: the script is not restartable
[09:13] <danilo> lifeless, ^^
[09:13] <gnuoy> lifeless: Hi
[09:14] <lifeless> danilo: it runs with the restartable flag
[09:14] <lifeless> danilo: thats a mistake I guess?
[09:14] <danilo> lifeless, fwiw, I also think we should find a way around bug 622670 for it to not get messed up like this
[09:14] <_mup_> Bug #622670: DBLoopTuner stalls over DB slave rebuilds <lp-foundations> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/622670 >
[09:14] <danilo> lifeless, I suppose so (I don't know what's the "restartable flag")
[09:15] <lifeless> danilo: look at lib/canonical/database/multitablecopy.py __init__
[09:15] <danilo> lifeless, it's perhaps restartable if temp tables are left in :)
[09:15] <lifeless> danilo: the tables it uses can be either TEMP or regular tables
[09:15] <lifeless> danilo: depending on that flag
[09:16] <danilo> lifeless, right, so it creates temp_* tables for real ones, doesn't it?
[09:16] <lifeless> danilo: the default is restartable, which means the tables are regular tables
[09:16] <danilo> lifeless, which seem to have just been dropped by stub?
[09:16] <lifeless> danilo: yeah, which we've just deleted because they broke slony and security.py
[09:16] <danilo> lifeless, so that kinda means it's not restartable, right?
[09:16] <lifeless> danilo: I guess
[09:16] <lifeless> :)
[09:17] <lifeless> danilo: sorry for any headaches added; the stall issue is indeed a nuisance
[09:17] <danilo> heh, ok :) it's restartable in general then, but not for now :) lifeless, how would you feel about having a flag for scripts like this in dblooptuner to let it wait a maximum of one hour, and if that has passed, continue with the work?
[09:18] <danilo> (iow, ignore the lag)
[09:18] <lifeless> I think we should special case building new replicas to not block anything else
[09:18] <lifeless> we need to move backups onto the slaves which slony2 will let us do (I *think*)
[09:18] <danilo> lifeless, right, we discussed that before, stub says it's too hard
[09:18] <danilo> lifeless, (in the above bug)
[09:19] <lifeless> let me refresh my memory
[09:19] <danilo> lifeless, sure thing; fwiw, I'd be happy to look into that when I switch to maintenance as well, since it's hitting more scripts in translations
[09:19] <stub> Given the bloat issues we are having, we might have to be more strict rather than less strict
[09:20] <stub> You might love scripts to complete faster, but you love a database that hasn't fallen over even more.

Deryck Hodge (deryck)
Changed in launchpad:
status: New → Triaged
importance: Undecided → Low
Changed in launchpad:
importance: Low → Critical
Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :

See also bug 891929. If we can make the script restartable, we may not need to deal with bug 576822.

William Grant (wgrant)
tags: added: lp-translations
Revision history for this message
Steve Kowalik (stevenk) wrote :

With the work in r16541, cleaning up is easier, so this can drop from Critical to High.

Changed in launchpad:
importance: Critical → High
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.