donate.wikimedia.org currently does not have an IPv6 address.
Description
Details
- Reference
- bz71267
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable IPv6 for donate.wm.o | operations/dns | master | +6 -6 |
Related Objects
- Mentioned In
- rODNSb86fbaa586a2: Enable IPv6 for donate.wm.o
- Mentioned Here
- T99226: Switch Varnish's GeoIP code to libmaxminddb/GeoIP2
Event Timeline
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
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?
@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?
@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.
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.
(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).