Hey @bd808, to have the dumps folks (plural!) on the task watching, you can either tag with the project tag or add also @Hokwelum so we both get notifications.

Note that download.wikimedia.org is mapped to the text-lb lvs's and it redirects to dumps.wikimedia.org, see T107575 for the back story which I no longer remember.

Change 793525 had a related patch set uploaded (by BBlack; author: BBlack):

[operations/puppet@production] Add dumps mapping to cache_upload

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

Thanks for this task, that's great!
Once this is done, could those severs live with private IPs to not "waste" public ones?
I see a mention of rsync on CR793525 for example, is that a blocker? What are the other flows on those boxes?

In T306550#7967853, @ayounsi wrote:

Once this is done, could those severs live with private IPs to not "waste" public ones?
I see a mention of rsync on CR793525 for example, is that a blocker? What are the other flows on those boxes?

This is a good question. I'm actually now wondering if the rsync wokflow will be broken by this change and if we need to make some intermediate change before we can put the http workflow behind the CDN.

There are 3 content serving workflows for these boxes. Two of the three, http and rsync, are public internet facing. The third, NFS exports, faces both the WMCS tenant network and the analytics network. There are two physical hosts currently. In normal operation one handles http + rsync and the other handles nfs.

Rsync use case is documented at https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps. The use of "dumps.wikimedia.org" as the rsync source will make pointing that hostname at dyna.wikimedia.org problematic.

Unassigning myself because I'm not actively working on this. This remains a somewhat difficult networking gray area.

Change 793525 abandoned by BBlack:

[operations/puppet@production] Add dumps mapping to cache_upload

Reason:

Ticket's stale, and this particular commit isn't the answer

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

For the rsync problem, I see roughly options here:

• Provision a separate host name like rsync.dumps.wikimedia.org, and ask the rsync mirror operators to update their clients to point to that. Then migrate the main dumps hostname to the CDN.
• Borrow the infrastructure set up in T408532: Deploy a TCP proxy across all DCs to handle the rsync port on the same hostname/VIP. This might not be ideal due to the relatively high bandwidth usage involved, plus it requires moving the firewalling stuff from the clouddumps hosts to the new proxies.

@taavi Could option 3 be something like what's currently being done for Gerrit ? {T365259}

In T306550#11378638, @ayounsi wrote:

@taavi Could option 3 be something like what's currently being done for Gerrit ? {T365259}

That's the second option in my comment.

Oops, I'm still catching up. Sounds great to minimize user impact. do we know how many systems pull from our rsync ? Maybe it's not worth the hassle of the tcp-proxy if the number is low enough.

In T306550#11378740, @ayounsi wrote:

do we know how many systems pull from our rsync ? Maybe it's not worth the hassle of the tcp-proxy if the number is low enough.

I count 8 active mirrors in the config at
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/production/hieradata/common/profile/dumps/distribution.yaml#31

profile::dumps::distribution::mirrors:
  - url: 'http://wikipedia.c3sl.ufpr.br'
    hostname: 'sagres.c3sl.ufpr.br'
    ipv4: ['sagres.c3sl.ufpr.br']
    ipv6: ['sagres.c3sl.ufpr.br']
    contactname: 'Carlos Carvalho'
    contactaddy: 'carlos@fisica.ufpr.br'
    institution: 'C3SL'
    addedby: 'atg'
    addeddate: 'Sept 6 2011'
    active: 'yes'
  - url: 'https://wikimedia.bytemark.co.uk'
    hostname: 'wikimedia.bytemark.co.uk'
    ipv4: ['wikimedia.bytemark.co.uk']
    ipv6: []
    contactname: 'Matthew Bloch'
    contactaddy: 'promotion@support.bytemark.co.uk'
    institution: 'Bytemark'
    addedby: 'reedy'
    addeddate: 'March 1 2017'
    active: 'no' # was: 'notyet'
  - url: 'http://ftp.fi.muni.cz/pub/wikimedia/'
    hostname: 'odysseus.fi.muni.cz'
    ipv4: ['odysseus.fi.muni.cz', 'odysseus.linux.cz']
    ipv6: ['odysseus.ip6.fi.muni.cz']
    contactname: 'Jan Kasprzak'
    contactaddy: 'ftp-admin@fi.muni.cz'
    institution: 'Faculty of Informatics, Masaryk University'
    addedby: 'atg'
    addeddate: 'May 11, 2012'
    active: 'no'
  - url: 'http://mirror.accum.se/mirror/wikimedia.org/dumps/'
    hostname: 'mirror.accum.se'
    ipv4: ['poincare.acc.umu.se', 'ftp.acc.umu.se', 'mirror.accum.se']
    ipv6: ['poincare.acc.umu.se', 'ftp.acc.umu.se', 'mirror.accum.se']
    contactname: 'Mirror admin'
    contactaddy: 'ftp-adm@accum.se'
    institution: 'Academic Computer Club, Umeå University'
    addedby: 'atg'
    addeddate: 'Oct 25 2016'
    active: 'yes'
  - url: 'http://mirror.fr.wickedway.nl/'
    hostname: 'mirror.fr.wickedway.nl'
    ipv4: ['mirror.fr.wickedway.nl']
    ipv6: []
    contactname: 'Mirror admin'
    contactaddy: 'mirror@wickedway.nl'
    institution: 'WickedWay Web Hosting'
    addedby: 'atg'
    addeddate: 'June 8 2012'
    active: 'no'
  - url: 'http://wikimedia.wansec.com/'
    hostname: 'none.example.com'
    ipv4: ['199.47.196.26', 'wikimedia.wansec.com']
    ipv6: []
    contactname: 'Robert Smith'
    contactaddy: 'rtsmith@wansecurity.com'
    institution: 'WANSecurity'
    addedby: 'atg'
    addeddate: 'unknown'
    active: 'no' # was: 'notrightnow'
  - url: 'http://dumps.wikimedia.your.org/'
    hostname: 'your.org'
    ipv4: ['ftpmirror.your.org', 'ftpmirror-ae0-4.us.your.org']
    ipv6: ['ftpmirror.your.org']
    contactname: 'Kevin Day'
    contactaddy: 'kevin@your.org'
    institution: 'Your.org'
    addedby: 'atg'
    addeddate: 'Feb 2 2012'
    active: 'yes'
  - url: 'http://wikimedia.iconic.vi'
    hostname: 'wikimedia.iconic.vi'
    ipv4: ['wikimedia.iconic.vi']
    ipv6: []
    contactname: 'Valentino Vaschetto'
    contactaddy: 'val@iconicindustry.com'
    institution: 'Iconic Industry'
    addedby: 'atg'
    addeddate: 'Apr 28 2016'
    active: 'no'
  - url: 'http://wikimedia.crc.nd.edu/other/'
    hostname: 'crcdtn01.crc.nd.edu'
    ipv4: ['crcdtn01.crc.nd.edu', 'wmrsync.crc.nd.edu']
    ipv6: []
    contactname: 'Matt'
    contactaddy: 'mvanderw@nd.edu'
    institution: 'Center for Research Computing, University of Notre Dame'
    addedby: 'atg'
    addeddate: 'Apr 25 2016'
    active: 'no'
  - url: 'https://aws.amazon.com/public-datasets/'
    hostname: 'amazonaws.com'
    ipv4: ['ec2-174-129-186-231.compute-1.amazonaws.com']
    ipv6: []
    contactname: 'unknown'
    contactaddy: 'unknown@example.com'
    institution: 'Amazon AWS'
    addedby: 'atg'
    addeddate: 'Oct 31 2012'
    active: 'no'
  - url: 'https://wikimedia.mirror.us.dev/'
    hostname: 'wikimedia.mirror.us.dev'
    ipv4: ['wikimedia.mirror.us.dev']
    ipv6: ['wikimedia.mirror.us.dev']
    contactname: 'Chip Wasson'
    contactaddy: 'wikimedia_mirror@wasson.io'
    institution: 'none'
    addedby: 'atg'
    addeddate: 'Aug 9, 2019'
    active: 'yes'
  - url: 'https://wikimedia.bringyour.com'
    hostname: 'wikimedia.bringyour.com'
    ipv4: ['65.19.157.35', 'wikimedia.bringyour.com']
    ipv6: ['wikimedia.bringyour.com']
    contactname: 'Brien'
    contactaddy: 'brien@bringyour.com'
    institution: 'BringYour'
    addedby: 'atg'
    addeddate: 'May 21, 2021'
    active: 'yes'
  - url: 'https://mirror.clarkson.edu'
    hostname: 'mirror.clarkson.edu'
    ipv4: ['mirror.clarkson.edu']
    ipv6: ['mirror.clarkson.edu']
    contactname: 'Christopher Mahoney'
    contactaddy: 'mirroradmin@clarkson.edu'
    institution: 'Clarkson University'
    addedby: 'hokwelum'
    addeddate: 'May 18, 2022'
    active: 'yes'
  - url: 'https://wikipedia.mirror.pdapps.org/'
    hostname: 'wikipedia.mirror.pdapps.org'
    ipv4: ['wikipedia.mirror.pdapps.org']
    ipv6: ['wikipedia.mirror.pdapps.org']
    contactname: 'Andrey Voronin'
    contactaddy: 'wp@pdapps.org'
    institution: 'PDApps'
    addedby: 'hokwelum'
    addeddate: 'Aug 17, 2022'
    active: 'no'
  - url: 'https://wikidata.aerotechnet.com/'
    hostname: 'wikisync.aerotechnet.com'
    ipv4: ['wikisync.aerotechnet.com']
    ipv6: ['wikisync.aerotechnet.com']
    contactname: 'Ryan Malecki'
    contactaddy: 'ryan.c.malecki@gmail.com'
    institution: 'none'
    addedby: 'hokwelum'
    addeddate: 'Mar 14, 2023'
    active: 'yes'
  - url: 'https://datasets.scatter.red/wikimedia/'
    hostname: 'orb1001.fihel1.scatter.red'
    ipv4: ['orb1001.fihel1.scatter.red']
    ipv6: ['orb1001.fihel1.scatter.red']
    contactname: 'James Hare'
    contactaddy: 'james@scatter.red'
    institution: 'none'
    addedby: 'hokwelum'
    addeddate: 'Apr 19, 2023'
    active: 'no'
  - url: 'https://datasets.orbopengraph.com/wikimedia/'
    hostname: 'data1.usrdm1.scatter.red'
    ipv4: ['104.255.173.26', 'data1.usrdm1.scatter.red']
    ipv6: ['data1.usrdm1.scatter.red']
    contactname: 'James Hare'
    contactaddy: 'james@scatter.red'
    institution: 'Scatter'
    addedby: 'xcollazo'
    addeddate: 'Jan 19, 2024'
    active: 'yes'

That count is a couple more than are listed at https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps

There are a few more hard coded into https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/production/modules/profile/templates/dumps/distribution/mirrors/rsyncd.conf.dumps_to_public.erb#82

Thanks, then as it's only a few, option 1 seems best to me. Much less complex to setup and maintain.
Setup the new FQDN, ask people to migrate, give them X months, check activity on the old one, send reminder email, move to the CDN.

Change #1213461 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/dns@master] Add dumps-rsync

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

Change #1213461 merged by Majavah:

[operations/dns@master] Add dumps-rsync

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

Change #1237187 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/dns@master] Add dumps-http.discovery.wmnet

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

Change #1237193 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dumps: web: Trust X-Client-IP from edge caches

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

Change #1237194 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] hieradata: Add dumps.wikimedia.org CDN mapping

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

Change #1237187 merged by Majavah:

[operations/dns@master] Add dumps-http.discovery.wmnet

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

Change #1237193 merged by Majavah:

[operations/puppet@production] dumps: web: Trust X-Client-IP from edge caches

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

This is still primarily blocked on T415193: Get dump mirrors to use new dumps-rsync service name (for DE).

In the meantime, some numbers/data:

• According to Netflow, in the past week the dumps HTTP endpoint has peaked at about 2.4 TiB served in an hour. That is (roughly, rounded up) about 6 gigabits/sec.
• The current dumps.wm.o nginx configuration sets a rate limit of ~5 megabytes/second after the first megabyte. There is also a limit of 3 concurrent connections per IP+UA pair. (These limits were last raised in 2019 in https://gerrit.wikimedia.org/r/c/operations/puppet/+/555632.)
• That is currently all served out of a single box, which most of the time is clouddumps1002 (in C4). These hosts have single 10G connections to their ToR switches.

In addition there's one more bit of complexity that we need to take account:

• The nginx access logs for these hosts are copied to stat* hosts for analysis. My understanding, which T119070 supports, is that those files are used by WMDE to gather data on how the Wikidata dumps are used. This mechanism does not seem to be properly documented anywhere.
• This mechanism relies on a single backend server receiving and logging all requests. I would imagine/hope that once behind CDN the same data could be pulled from the CDN access logs instead, but until then, caching files at the edge or load-balancing requests between the two clouddumps hosts would disrupt this data.

With that being said, tagging Netops and Traffic for your questions, concerns and advice. Are those numbers fine from the CDNs and backhaul links point of view?

It would be helpful to state the desired goals here: Is this for protections via requestctl? Caching?

On the netops side the main advantage is to not require real servers to use public IPs. The benefits are listed on https://wikitech.wikimedia.org/wiki/Wikimedia_network_guidelines#Public_IPs
Benefiting from all the tooling, infrastructure and expertise of the traffic team is also very valuable.

@BBlack should weigh in here. We consulted him on this topic earlier this year, and the recommendation was that Dumps should not be behind the CDN because of the long lived connections.

The main motivation for exploring that space/making the ask in the first place is wanting to have UA policy enforcement on the dumps website, since it is currently out of scope (see: T400119: Block traffic from user-agents not honoring our policy). I agree that having the additional tooling for things like the web request table and flags that are calculated at the edge would be valuable, but it sounded like it might not be worth the trade-offs.

In T306550#11624133, @BCornwall wrote:

It would be helpful to state the desired goals here: Is this for protections via requestctl? Caching?

The initial trigger for this was what @ayounsi mentioned. If these could leverage caching as well, that would be a major benefit from our point of view as well.

In T306550#11648833, @HCoplin-WMF wrote:

@BBlack should weigh in here. We consulted him on this topic earlier this year, and the recommendation was that Dumps should not be behind the CDN because of the long lived connections.

The main motivation for exploring that space/making the ask in the first place is wanting to have UA policy enforcement on the dumps website, since it is currently out of scope (see: T400119: Block traffic from user-agents not honoring our policy). I agree that having the additional tooling for things like the web request table and flags that are calculated at the edge would be valuable, but it sounded like it might not be worth the trade-offs.

I'm surprised to hear that there have been conversations about the dumps distribution infrastructure that my team hasn't been involved in (to my knowledge). The current setup, which is serving all dumps.wikimedia.org HTTP requests off of hard drives on a single host is running at its limits (and has been for a while), and the overloading of these hosts is a major pain every time we have to do any routine maintenance on them.

(FWIW, a major reason these connections are so long-lived is the rate limiting that's there to try to handle all of the traffic from so little infrastructure. Offloading at least the most frequently used files to the CDN might possibly help with that?)

In T306550#11651360, @taavi wrote:

(FWIW, a major reason these connections are so long-lived is the rate limiting that's there to try to handle all of the traffic from so little infrastructure. Offloading at least the most frequently used files to the CDN might possibly help with that?)

Any file larger than (I think) 512MB doesn't presently get cached in the CDN ever, which might be another obstacle here.

Trying to pull these threads together for a bit of context. The question that isn't explicitly answered fully is this:

In T306550#11624133, @BCornwall wrote:

It would be helpful to state the desired goals here: Is this for protections via requestctl? Caching?

The reason for this question is that "put X behind the CDN" often carries a lot of assumptions behind it, and we want to make sure whatever path we go down doesn't fail to meet implicit expectations. That being said, I can infer some of the answers from other comments

The easy ones seem to be:

• We want the actual dumps server to be on a private IP behind something else, instead of directly-public: our LVS layer can provide that L3/L4 (with dumps itself still terminating TLS), or the CDN at L7 (where the CDN terminates TLS), depending on the solution.
• We want the basic HTTP-layer defenses of the CDN to avoid some scraping impact, enforce UA policy, etc. The CDN can provide that!
• We want standardized analytics available through webrequest. The CDN provides that as well!

In the slightly-trickier bucket is rsync concerns:

The full CDN stack doesn't support rsync (or other non-HTTP protocols). A tcp proxy solution is possible, but that's just a pass-through and doesn't really buy much. The option of telling the few consumers of the rsync to change the hostname/IP they're using to mirror us (to separate it from HTTP via the CDN) would be far simpler and avoid the need for such a proxy. The rsync IP could be handled at just the LVS layer, while the HTTP hostname could go through the CDN.

And then we get to the bucket of concerns around load, bandwidth, long connection times, etc...

• Dumps hosts large files by its nature. In general, our HTTP caches aren't fond of large files. They displace a lot of smaller content. We cap even backend caching on the upload cluster at 1GB max, after which everything just passes through from the Swift backends. Even the larger files that do fit within that cap are already problematic for us, and changes are probably coming in this area to address them. Also, large files plus slow consumers tend to tie up concurrency in the CDN, which is a finite global resource and often critical for handling incidents and spikes.
• @taavi mentions that the dumps machine has peak outputs around 6Gbps, and only a 10Gbps interface. The implication is that the number might naturally be even higher if it weren't for the limitations of this one machine and its interface. 6Gbps (or more) is a lot of outbound bandwidth no matter how we service it. Adding this additional pressure to our CDN edge may not be wise under current conditions, and if the the distributed CDN edge manages to push these numbers up to a naturally-higher limit (perhaps through the caching of smaller dumps files that are popular), may even create larger problems.

It would be helpful to understand some of the expectations around the above stuff better.

• How large are the largest files dumps serves?
• Are there a lot of popular small ones, too?
• What does the distribution of response transfer sizes look like today in practice?
• Are we actively trying to reach higher output bandwidth by moving to the CDN, than the ~6Gbps that we suspect is a limitation of the dumps machine more than anything else? That might be a whole other conversation about resourcing and design for that.

I can hopefully answer some of those questions:

1. How large are the largest files dumps serves? Dumps are partitioned such that each compressed, downloadable file is roughly 2GB. When pulling the full English Wikipedia content history, there are just shy of 300 of those (I think it's like slightly over 280ish). Medium wikis are ~20-30 files, and smaller projects may only have a single partition.
2. Are there a lot of popular small ones, too? For database backup dumps, Wikipedia projects (and specifically English wiki) are by far the most popular (~1M unique downloads per month, deduped for the file chunking). Other project types (Wiktionary, Wikibooks, Wikidata) see about a third or less of that traffic. I also currently don't have additional divisions by language, but can get that if you need it.
3. What does the distribution of response transfer sizes look like today in practice? (I can't answer this one)
4. Are we actively trying to reach higher output bandwidth by moving to the CDN, than the ~6Gbps that we suspect is a limitation of the dumps machine more than anything else? That might be a whole other conversation about resourcing and design for that. There is currently no product need to increase download speeds. In fact, I believe that outgoing bandwidth is intentionally capped on the dumps website, but I would need to double check that.

The option of telling the few consumers of the rsync to change the hostname/IP they're using to mirror us (to separate it from HTTP via the CDN) would be far simpler and avoid the need for such a proxy.

This was done via T415193: Get dump mirrors to use new dumps-rsync service name.

How large are the largest files dumps serves? Dumps are partitioned such that each compressed, downloadable file is roughly 2GB. When pulling the full English Wikipedia content history, there are just shy of 300 of those (I think it's like slightly over 280ish). Medium wikis are ~20-30 files, and smaller projects may only have a single partition.

This is true of the legacy XML dumps, but the new File Export system, which is now in production running jointly with the legacy system, is currently tuned to generate files of ~512MB in size. For enwiki this means about 3290 files for a full history dump. If needed, we could tune this to generate smaller files even, at the expense of more files.

We expect to wind down the legacy XML dumps at some point in the future.

In fact, I believe that outgoing bandwidth is intentionally capped on the dumps website, but I would need to double check that.

That is correct. Here is the current definition, which caps downloads at 5 MB/s after the first 1MB, and caps client IPs to a max of 3 concurrent connections. This was last revised in 2019.

the new File Export system, which is now in production running jointly with the legacy system, is currently tuned to generate files of ~512MB in size. For enwiki this means about 3290 files for a full history dump. If needed, we could tune this to generate smaller files even, at the expense of more files.

Thanks for the context, @xcollazo ! I hadn't heard that before. Appreciate the correction :)

On the technical front:

• Both the object size (0.5GB) and the total dataset size (~1.6TB just for enwiki, larger for the whole collection) are too-large to run through any of our existing cache storage architecture as cacheable objects.
• 0.5GB file sizes are costly to cache: we may have to evict many thousands of smaller objects just to fit one of these, and the impact on eviction latency and general hitrate from bringing in a new source of thousands of these would be problematic just at that level.
• Our whole per-cluster caching dataset size in the CDN is on the order of about 13TB (either cluster). Eating up ~10% or more of that just for dumps files would have too-large an impact on our total cache storage. One might note that we already cache siimlarly-sized files and datasets from the Commons originals in cache_upload, but those are already problematic-enough under scraping that there are design efforts ongoing to eliminate them from our caching (and just stream them from source material directly, probably not even through any cache daemons). We certainly can't add more pressure to that already tough situation.
• If we put dumps behind the CDN without caching, then given the existing download speed caps and the sizes of the files (and the possibility of scraping): if they're at all popular (or become temporarily-popular!), one would expect very long lived connections slowly transferring the uncached data through our two layers of cache daemons. These would tie up precious concurrency resources that we're already starved for when under duress. Again, in general, we're trying to trend the other direction to fix existing problems: reduce object sizes, reduce timeouts, reduce connection durations, etc, and this would put more pressure on the caches during the unfortunately-common scraping and DDoS events that are ongoing, and so it's a no-go.

A long-term, broader view of these issues

Multiple other cases have also recently arisen that fit this same pattern (lists, gerrit, etc). The general pattern is that public-facing service X, which previously was not behind the CDN, now wishes to be behind the CDN. Generally these services are uncacheable for one or more reasons (and/or their caching is trivial and unimportant), and the real reason they want to be "behind the CDN" is to take advantage of the various defensive mechanisms at the very front of the CDN against various forms of attacks/scraping/exploitation, and/or to take advantage of standardized webrequest analytics flows vs custom logging. However, it's also not uncommon that the caching parts of the CDN really are not a good fit for the service's traffic, and the CDN's performance and resiliency for primary wiki traffic may suffer if we onboard these services to the shared CDN infra.

What we need here, in the long term, is the ability to logically split what we could call the WAF part of the CDN from the concurrency/size-sensitive caching parts, so that we can offer just the WAF part to cases like dumps easily, and keep the traffic flows separated from the primary CDN cluster(s) altogether.

The general shape of this would be to offer a puppetized WAF HTTP proxy service that can be deployed onto ~any server in our infrastructure (or to a shared proxy machine/instance covering several smaller miscellanous public services), and which is configured for all the same kinds of defenses as the CDN's front edge, but in a generic form and with little-to-no actual caching capabilities. Possibly also in scope for this would be HaproxyKafka -driven analytics data flows as well, ideally.

Unfortunately, this is not a trivial project. The defensive implementation pieces are built from both manual and Requestctl -based rules, and some of the defenses deploy via the haproxy layer while others deploy via Varnish VCL code at the next layer down. The kafka parts will obviously need some thinking and cross-team coordination as well (we might want a separate non-CDN variant of the webrequest streams and tables for these other use-cases, rather than polluting the existing webrequest). Extracting all of this into a separate generic, backend-agnostic form is a Real Project. Traffic is going to look into this for future planning Soon, but they don't yet know how it will play out in terms of priorities in the coming quarters. In any case, even if that effort starts Soon, it's not really a short-term solution for the ongoing issues for Dumps.

Nearer-term option for dumps:

As I understand it, the primary pressing need on the Dumps front is just basic hard-enforcement of our UA policy, and that might tide us over until the above is ready. We think this could be implemented as a limited one-off solution for dumps, directly in the existing HTTP proxy config of the dumps machine, fairly quickly with Traffic resources doing the bulk of the work. We'll circle back on the timing/resourcing by early next week.

This ticket:

This ticket is now fairly ancient, and I don't think the literal title of it is going to ever be the outcome here. It might make sense to replace it with fresher tickets about the short- and long- term plans here sometime in the next week or three as related details are ironed out.

Change #1237194 abandoned by Majavah:

[operations/puppet@production] hieradata: Add dumps.wikimedia.org CDN mapping

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