Feature #49


BugZilla migration

Added by Florian Effenberger over 10 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:




BugZilla should be migrated to our own instance at, preferably as KVM container

Subtasks 1 (0 open1 closed)

Feature #80: Setup Bugzilla VMClosedAlexander Werner2014-01-30

Actions #1

Updated by Christian Lohmaier over 10 years ago

  • Status changed from New to Feedback

requires feedback from Tollef...

Actions #2

Updated by Florian Effenberger over 10 years ago

Thorsten: So far no news from Tollef. Can you ping him again, you might know him a bit better? It blocks currently on his work/feedback...

Actions #3

Updated by Florian Effenberger over 10 years ago

  • Start date deleted (2014-01-14)
Actions #4

Updated by Florian Effenberger over 10 years ago

  • Assignee changed from Christian Lohmaier to Alexander Werner

Joel poked me today whether it's possible to - as intermediate solution (solely!) for some preparations and tests - have an instance hosted at gru. Either Alex or Christian could have a look at setting it up via KVM. Drawback is that we only have one IP on the machine so far, so 22, 80 and 443 are already taken as ports for services


Actions #5

Updated by Alexander Werner over 10 years ago

  • Category set to Virtualization
Actions #6

Updated by Florian Effenberger over 10 years ago

We're still waiting for feedback from
If you do not hear back within a week from me, we should go on with setting up a VM, where then Robinson and Joel can install BugZilla onto (so they need access to it as well)

The plan is:

- TDF sets up a VM and takes care of getting BugZilla per se (that is, without data so far) up and running there

- We then need at least read-only access to the underlying database and the files of the current instance (IIRC, one can attach files to BugZilla that do not end up in the database); either directly on the host so we grab it ourselves, or as an archive somewhere

- With a first copy of this data, we then try to put the data into our BugZilla, to end up with a clone that should have the same functionality as the current FDO instance

- If the data import works, we arrange a date and time where the FDO instance will be closed/put read-only (most probably only Tollef can do that), we do another database and file dump, and put our new instance live

Actions #7

Updated by Norbert Thiebaud over 10 years ago

Tollef took care of creating a sanitized backup of fdo bugzilla
I downloaded it on vm14 and restored the postgress 'bugzilla' database (user bugz)
I picked the same name than were in the backup for simplicity sake

what is left:

1/ install bugzilla. note that the version schema of the bugzilla database we receive is 3.00 so we need a version of bugzilla that match that schema.
2/ configure nginx to serve bugzilla pages
3/ sanity check that the restored database is usable and contains what we expect. Note: I dids some select etc.. directly in the database, it looks quite good.
4/ drop the bugzilla database and re-restore it.. make sure bugzilla is not unhappy with that.

if these step are satisfactory:
4/ prepare a production VM
5/ install and prepare bugzilla on it...
6/ restore a test backup.. make sure everything is fine.. then drop it again

7/ prepare a landing static web-page to be displayed while the migration is on-going at

8/ schedule a migration date 'D' with tollef.

9/ D - 72/48 hours... (depending on the current ttl) change the ttl on to a small value... 5 minutes ?

10/ D-Day... meet Tollef on IRC.. make sure everything is ready...
11/ fdo turn their ugzilla off for maintenance
12/ we switch the DNS entry for to our production box.. which display the landing page of 7/
13/ fdo does a backup, restore, scrub and rebackup (how long that will take is TDB.. but a couple of hours max is anticipated for now)
14/ we download the sanitized backup (~30 minutes)
15/ we restore the database (~10 minutes)
16/ we swithc bugs.libreoffice/org to bugzilla itself instead of the landing page
17/ Tollef put in place a set of redirect rules on fdo side to redirect individual bugs url to us, for the bugs that are LibreOffice related.
18/ fdo turn off LibreOffce project on their bugzilla, and scrub things up.
19/ restore the ttl to a more reasonable value...

20/ we remotely share a beer :-)

as a side note. we will then have both gerrit and bugzilla being heavy user of postgresql... it would be a good idea to look into database replication... to replicate both gerrit and bugzilla to a 3rd box.. that would provide a continuous hot backup.

Actions #8

Updated by Florian Effenberger about 10 years ago

  • Assignee deleted (Alexander Werner)

Right now, nothing to do for Alex IMHO, so removing task assignment (otherwise the sorting and prioritizing of tasks becomes tedious if there alibi tasks :)
Feel free to re-assign when infra can help out

Actions #9

Updated by Robinson Tryon almost 10 years ago

Setting up planning meeting this week with Joel and Norbert.
Aiming to layout roadmap and schedule.

Actions #10

Updated by Florian Effenberger over 9 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF