Page MenuHomePhabricator

Move Bugzilla to old-bugzilla.wikimedia.org
Closed, ResolvedPublic

Description

During the migration, the current https://bugzilla.wikimedia.org will be set in read-only mode (that is T1234) and moved to old-bugzilla.wikimedia.org until further notice.

Details

Reference
fl551

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolvedmmodell
Resolvedchasemp
ResolvedDzahn
Resolvedmmodell
ResolvedDzahn
Resolved JohnLewis
DeclinedNone
ResolvedDzahn
ResolvedQgil
Resolvedchasemp
Declinedchasemp
Resolvedchasemp
Duplicatechasemp
Declinedchasemp
Invalidchasemp
Duplicatechasemp
ResolvedQgil
Resolvedchasemp
ResolvedAklapper
ResolvedQgil

Event Timeline

flimport raised the priority of this task from to Normal.Sep 12 2014, 1:46 AM
flimport set Reference to fl551.

aklapper wrote on 2014-08-28 19:24:26 (UTC)

I've also asked on https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/aUzv2vNLduo if there are better recommendations.

For the records/followup, my post only got one reply basically repeating/confirming what I wrote above.

aklapper wrote on 2014-09-07 15:44:32 (UTC)

For the records, I tried this yesterday on a local instance with several accounts and above steps work as expected (tested: changing fields; adding comments; accessing security tickets)

Qgil added a subscriber: Qgil.Sep 17 2014, 7:52 PM
Aklapper claimed this task.Sep 18 2014, 3:37 PM
Aklapper set Security to None.
jayvdb added a subscriber: jayvdb.Oct 21 2014, 3:26 PM
Qgil added a comment.Oct 25 2014, 7:39 AM

We need to agree on the URL of the archived version. @chasemp suggested old-bugzilla.wikimedia.org. Works for me.

+1. old-bugzilla.wikimedia.org works for me.

Question: will the migration script add a "Converted to Phabricator TNNNNN" comment to the bugs it migrates in old-bugzilla?

I added this as T934, IMO it's a nice-to-have.

In T366#15872, @Spage wrote:

Question: will the migration script add a "Converted to Phabricator TNNNNN" comment to the bugs it migrates in old-bugzilla?

No it won't, and I'm not sure if triggering hundreds of thousands of emails is really a good idea. :)

Qgil added a comment.Oct 28 2014, 7:44 AM

A frequent question: how long will old-bugzilla.wikimedia.org be available? Can we say something like:

At this point we have no plan to decommission old-bugzilla.wikimedia.org. Expect years, a community decision, and a deprecation window of at least six months.

Qgil renamed this task from Switch Bugzilla to being read-only when starting data migration to Phabricator to Move Bugzilla to old-bugzilla.wikimedia.org as a read-only instance.Oct 30 2014, 9:28 PM
Dzahn added a subscriber: Dzahn.Nov 7 2014, 8:35 PM
In T366#16004, @Qgil wrote:

A frequent question: how long will old-bugzilla.wikimedia.org be available? Can we say something like:

At this point we have no plan to decommission old-bugzilla.wikimedia.org. Expect years, a community decision, and a deprecation window of at least six months.

I would strongly advise to NOT keep Bugzilla up in the current from longer than needed. Saying "expect years" means "for years the ops team will have to patch it for every security release and version upgrade" even though almost nobody will use it. It already did not get much love when it was the main bugtracker, it will only become worse if it's "old-bugzilla" and has no users, but it would still need support. Already while we speak there is a complicated pending patch that deals with our custom modifications as well. What i would suggest instead:

  • keep static HTML of the bug pages. let's run a script that goes through all bug numbers, starting from 1 and simply saves the raw HTML. Then we can keep those static HTML files somewhere for years and nobody would mind. But we could delete the entire application, all the Perl files, anything dynamic and not have to deal with it ever again.
  • and/or provide a sanitized database dump to the general public. remove the user table and the security related bugs from a database dump, then put it on dumps.wikimedia.org or something for the community to download. people generally like that when we just release dumps and they are free to work with them

this, combined with the bugzilla.wikimedia.org URLs still working and being handled by phab itself, sounds good to me without having to care about actual BZ application

Qgil added a subscriber: Dzahn.Nov 7 2014, 9:07 PM

@Dzahn, every single line you wrote makes sense to me. This is a better solution.

do we want to make a ticket for creating a static reference version of bugzilla and/or a shareable dump then?

In T366#20065, @chasemp wrote:

do we want to make a ticket for creating a static reference version of bugzilla and/or a shareable dump then?

Done: T1198: Bugzilla HTML static version and database dump

Qgil removed Aklapper as the assignee of this task.Nov 10 2014, 11:46 PM

As explained in our team meeting today, Andre cannot be the owner of this task, he hasn't got permissions to do the move.

reading the description above, it describes how to make BZ read-only using the admin web ui, which andre__ should have access to. which other permissions are needed for which steps? is it about the DNS change only?

Qgil added a comment.Nov 10 2014, 11:54 PM

Yes, sorry, we want to play safe assigning tasks to the people that can resolve them. Andre can do the change to read-only, but he cannot do the change of domain. This is why I created T1234. The description of this task needs to be adjusted.

Qgil renamed this task from Move Bugzilla to old-bugzilla.wikimedia.org as a read-only instance to Move Bugzilla to old-bugzilla.wikimedia.org.Nov 10 2014, 11:54 PM
In T366#21275, @Qgil wrote:

but he cannot do the change of domain.

we should list what exactly the change should be like. was this the plan, mukunda ?

https://gerrit.wikimedia.org/r/#/c/172448/

that won't work though, because iridium, the phabricator host, does not have a public IP, the BZ server zirconium does.

DNS changes can be suggested by anyone. also for adding bugzilla-old we will need one. just needs ops to merge

Aklapper updated the task description. (Show Details)Nov 11 2014, 1:08 PM

here are Gerrit changes i prepared for the switch that makes bugzilla.wikimedia.org (and bugs.wm and bugzilla-attachment.wm) point over to the phabricator prod server (iridium).

these need to be merged by an ops once we have a "go" that phabricator can accept bugzilla URLs to handle them and get redirect by Mukunda's scripts.

one change switches the DNS from zirconium (current Bugzilla) to misc-web (the misc. varnish caching cluster address) (phabricator is behind this and doesn't have a public IP so we don't point to iridium directly)

the other is the varnish config change that makes misc-web know to forward bugzilla requests to backend iridium (prod phabricator)

i should have reversed first/second. the varnish change should go first:

https://gerrit.wikimedia.org/r/#/c/172471/

then

https://gerrit.wikimedia.org/r/#/c/172469/

Qgil assigned this task to Dzahn.Nov 23 2014, 10:16 PM

https://old-bugzilla.wikimedia.org/ and it's working.

Currently it is lacking a certificate, but this should be solved during Monday or so. This is the only reason why we are not marking it resolved yet.

Let me say Big Thank You to @Dzahn, who helped us during this weekend on this task and more!

Dzahn closed this task as Resolved.Nov 25 2014, 2:23 AM

we solved this issue by moving old-bugzilla behind misc-web varnish/nginx layer instead.

that way it gets to use the wildcard *.wikimedia.org cert and we don't have to buy anything, but the error should be gone.

related changes:

https://gerrit.wikimedia.org/r/#/c/175595/
https://gerrit.wikimedia.org/r/#/c/175601/
https://gerrit.wikimedia.org/r/#/c/175615/
https://gerrit.wikimedia.org/r/#/c/175646/

so the issue is resolved but i'm technically saying "rejected" because we won't buy a new cert :)

Dzahn added a comment.Nov 25 2014, 2:25 AM

P.S. we also had to disable _ssl_redirect option in Bugzilla app itself, before we got a redirect loop.

setting could just be live hacked by editing ./bugzilla/data/params directly on shell
'ssl_redirect' => '0',