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)

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. :)

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.

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

@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

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?

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.

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

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/

The outstanding cert issue for old-bz is tracked in https://rt.wikimedia.org/Ticket/Display.html?id=8922

Related patches for DNS, Puppet, etc (as far as I have an overview):

• https://gerrit.wikimedia.org/r/#/c/172469/
• https://gerrit.wikimedia.org/r/#/c/175133/
• https://gerrit.wikimedia.org/r/#/c/175139/
• https://gerrit.wikimedia.org/r/#/c/175136/
• https://gerrit.wikimedia.org/r/#/c/175144/
• https://gerrit.wikimedia.org/r/#/c/175128/
• https://gerrit.wikimedia.org/r/#/c/175162/

In the admin UI config of BZ, the "urlbase" and "sslbase" value were adjusted.

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',