I wrote the code to redirect based on regex of the urls and map to the phabricator reference fields... just need to work with chase to actually deploy it.

In T41#5387, @mmodell wrote:

I wrote the code to redirect based on regex of the urls and map to the phabricator reference fields... just need to work with chase to actually deploy it.

@mmodell: Any public link to the code? Is this in Gerrit or where could this be found? (Also see T197).

i figure if it's written in PHP and since RT is written in Perl, first we'd have to install PHP on the RT server, magnesium.

do you need a change for that? you want to deploy this on the RT server itself, right?

are we able to exclude the URLs to tickets in the queues that are supposed to run longer than the other ones?

There isn't really a good handle on redirecting _some_ queues from RT. I think that wasn't envisioned at the beginning. For BZ we are going to move DNS over and handle the domain directly, for partial RT move...I dunno. ideas? @mmodell?

I checked. magnesium already has php5-cli, php5-mysql, libapache2-mod-php5 sounds to me like we are likely covered already.

any other requirements your script has? if you link me to the code i can help deploying it

In T41#14112, @Dzahn wrote:

magnesium already has php5-cli, php5-mysql, libapache2-mod-php5 sounds to me like we are likely covered already.
any other requirements your script has? if you link me to the code i can help deploying it

ping - anybody who can provide a link? or are we all fine?

In T41#14112, @Dzahn wrote:

I checked. magnesium already has php5-cli, php5-mysql, libapache2-mod-php5 sounds to me like we are likely covered already.

any other requirements your script has? if you link me to the code i can help deploying it

ping - anybody who can provide a link? or are we all fine?

FWIW per @mark we are not going to be redirecting URL's at the beginning as we are leaving behind a few queues and RT will still be a first class citizen in some cases. So this isn't really a blocker for RT ....day one :) if I understand correctly.

Per @mark... where?

In T41#798556, @Krenair wrote:

Per @mark... where?

Live conversation :)

imho this (not being a blocker in the beginning) doesn't mean we shouldn't be working on this task. can we get the script into git nevertheless and review it, try it in labs, prepare the puppet change to deploy it etc, then merge just the labs->prod switch when needed. that would prevent having to do it last minute

In T41#798743, @Dzahn wrote:

imho this (not being a blocker in the beginning) doesn't mean we shouldn't be working on this task. can we get the script into git nevertheless and review it, try it in labs, prepare the puppet change to deploy it etc, then merge just the labs->prod switch when needed. that would prevent having to do it last minute

agreed, good to get done no matter what, just relaying the info :)

mukunda, hi, this is going to be handled like the Bugzilla redirects too, right? so we could add it before the actual switch, before we change DNS, and then we could already test it by hacking /etc/hosts

This will NOT happen before the actual switch. See T38#844527

We still have a queue stuck in rt so we can't redirect the url. Stalled
for sure but valid

What was the use case for this anyway?

I believe all RTs included the RT ticket nr anyway. I think the limited user base of RT is smart enough to be able to search for the RT number in Phabricator now, so not sure this is worth the effort.

What @mark says makes sense. Declined?