Page MenuHomePhabricator

Enable IPv6 on donate.wikimedia.org
Closed, ResolvedPublic

Description

donate.wikimedia.org currently does not have an IPv6 address.

Details

Reference
bz71267

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:54 AM
bzimport set Reference to bz71267.
bzimport added a subscriber: Unknown Object (MLST).
Dzahn removed Dzahn as the assignee of this task.Feb 25 2015, 12:41 AM
Dzahn assigned this task to Jgreen.
Dzahn added a subscriber: Dzahn.
faidon raised the priority of this task from Low to High.Sep 3 2015, 12:18 AM
faidon updated the task description. (Show Details)

I'm not sure if there's anything that prevents IPv6 from being enabled on donate; if so, could we have it detailed in this task?

Adding IPv6 to donate would make no positive functional difference to actual donations as a) the vast majority of clients is dual-stacked), b) payments/frack is still IPv4-only.

As for "why": all of production is currently IPv6-enabled for the past 3 years now and this is an exception to it. Global IPv6 traffic is currently almost at 7% and rising quickly. There are also potential performance problems from having donate as IPv4-only, as this breaks SPDY/HTTP2 coalescing with the main site; resources from donatewiki are sometimes included in the main projects (e.g. the recent mobile app banner) and this would be slower to load, potentially worsening the experience for IPv6-enabled users.

Assigning an IP and adding it to our GeoDNS is trivial, so at this point the only blocker is for fr-tech to lift their objection. @Jgreen/@K4-713 what do you think?

Change 235749 had a related patch set uploaded (by BBlack):
Enable IPv6 for donate.wm.o

https://gerrit.wikimedia.org/r/235749

Actually, it was implemented currently via "text-addrs-v4". Simply removing the trailing "-v4" in a few places fixes this, as shown in the proposed patch above.

Assigning an IP and adding it to our GeoDNS is trivial, so at this point the only blocker is for fr-tech to lift their objection. @Jgreen/@K4-713 what do you think?

Just spoke with K4-713 about this: donate.wm.o geolocates clients who are following non-banner links (e.g. email campaign links). Early on the ipv6 geocoding data was spotty so we were concerned that we'd have too many ipv6 users being kicked into the payment process as though they're in the wrong country. We don't expect this to be a big issue now, and there's no objection. However, we should alert Caitlin C when the change goes into effect so she can be on the lookout for a significant increase in users complaining about payment geography.

@Jgreen - Is the payment geography something custom in FR's software, or is it our standard GeoIP cookie stuff we use on the main sites?

Assigning an IP and adding it to our GeoDNS is trivial, so at this point the only blocker is for fr-tech to lift their objection. @Jgreen/@K4-713 what do you think?

Just spoke with K4-713 about this: donate.wm.o geolocates clients who are following non-banner links (e.g. email campaign links). Early on the ipv6 geocoding data was spotty so we were concerned that we'd have too many ipv6 users being kicked into the payment process as though they're in the wrong country. We don't expect this to be a big issue now, and there's no objection. However, we should alert Caitlin C when the change goes into effect so she can be on the lookout for a significant increase in users complaining about payment geography.

@CCogdill_WMF - Are you ok with targeting this for Monday the 14th?

@BBlack thanks for the heads up, I think that's fine if fr-tech is OK with it. @MBeat33 should be in the loop since he manages the Donor Services queue.

I'm planning on sending a big email blast to Belgium and Luxembourg on Monday at 9am UTC, and I'm thinking those small countries may be ripe for geolocation issues in this case. We don't usually force country in our email links - do you think I should for this blast until we can say for sure this doesn't cause too many problems?

We can also just wait to do this until after you're done with that email.

@BBlack emails are most productive in their first 24 hours, so I wouldn't mind waiting until Tuesday, 9/15 if that works for you.

@BBlack We have a banner campaign planned to go up in Luxembourg and Belgium on Monday morning UTC time. Should we postpone this launch until Tuesday? Thank you.

@jrobell AFAIK this change won't affect banners. The main sites already use IPv6, this change is only for donatewiki.

Related: it seems T99226 would improve IPv6 geolocation. Is someone looking at that?

We haven't had the time to devote to it yet, it's just a matter of scheduling and priorities.

Thank you @Pcoombe, as this doesn't seem to affect banner campaigns, the planned Luxembourg and Belgium campaign just went up at 1.30 pm UTC.

Are we still good to go for this? I had planned to push this change Tues or Weds, but finally have some time to come back around to it today.

@BBlack thanks for the update. There was an email sent out to Italy donors this morning that might be affected by this deployment.

@CCogdill_WMF : Could you confirm with BBlack if he can push this out or if we should hold off. Thanks!

@BBlack no emails will be going out for the rest of the week, so today or tomorrow would be great. I'm assuming gerrit or something will update this task when you deploy - but if not, let me know when I should start keeping an eye out for issues.

Thanks! I'm going to do it now, and yeah gerrit will log the merge here regardless.

Change 235749 merged by BBlack:
Enable IPv6 for donate.wm.o

https://gerrit.wikimedia.org/r/235749

(btw, the relevant TTLs are 600s, so you may not see the full effect for at least 10 minutes. Maybe longer for some clients, if they have bugger resolver caches that hold outdated records longer than they should).

BBlack raised the priority of this task from High to Needs Triage.
BBlack moved this task from Triage to Done on the Traffic board.