[08:16:29] <topranks>	 taavi: hey, I'm looking for the first time at 'reverse-proxy.php' in the mediawiki-config repo 
[08:16:46] <topranks>	 context is I think you advised bre tt to add the new eqsin ranges there?
[08:17:07] <topranks>	 I was going to add the new ulsfo ranges we added last month too... but I do wonder about the file in general 
[08:17:34] <topranks>	 eqiad/codfw have a _lot_ of ranges, is there a reason we wouldn't just put in the aggregates we use on each site than each vlan subnet?
[08:18:33] <topranks>	 or tbh we could even just have 10/8 and our IPv6 "private" allocations?
[10:05:24] <brouberol>	 tappof you have pending changes on puppet. Are they gtg?
[10:05:36] <brouberol>	 (labs/private)
[10:14:38] <brouberol>	 given that this is only CI secrets, I'm going to go ahead and merge
[10:41:23] <taavi>	 topranks: tbh at this point I'd like some other team to properly take ownership of dealing with that and make that decision, since at this point I am getting a bit tired of having to remind of its existence basically every time it needs changes
[10:41:48] <topranks>	 taavi: I can empathise with that 
[10:41:49] <taavi>	 in the past the concern was that we don't want to have the analytics nets etc to have the ability to spoof the sender for mediawiki app requests
[10:42:01] <topranks>	 ok that is good context 
[10:43:12] <topranks>	 it's a shame we didn't allocate separate ranges for analytics, they are all over teh shop 
[10:43:33] <topranks>	 let me submit a patch to redefine it how I think might be sensible 
[10:43:40] <topranks>	 is there anyone else that should have eyes on it?
[10:44:57] <jayme>	 !incidents
[10:44:58] <sirenbot>	 8058 (ACKED)  ATSBackendErrorsHigh cache_upload sre (swift.discovery.wmnet eqiad)
[10:44:58] <sirenbot>	 8057 (RESOLVED)  HaproxyUnavailable cache_text global sre (thanos-rule@main)
[10:44:58] <sirenbot>	 8056 (RESOLVED)  VarnishUnavailable global sre (varnish-text thanos-rule@main)
[10:44:58] <sirenbot>	 8054 (RESOLVED)  ProbeDown sre (10.64.16.101 ip4 phab1004:443 probes/custom http_phabricator_wikimedia_org_ip4 eqiad)
[10:44:58] <sirenbot>	 8053 (RESOLVED)  ATSBackendErrorsHigh cache_upload sre (swift.discovery.wmnet eqiad)
[10:53:23] <btullis>	 topranks: could you cc me on it please, just so I can try to fathom it? I might not have anything useful to add in terms of review.
[10:54:06] <topranks>	 btullis: yes happy to, tbh I'm just trying to work out what might work best... and there is a script I was unaware of to generate the current file 
[10:54:44] <topranks>	 I'm muddling through now to see if I can arrive at a good set of aggregates that can replace the existing, and also will cover any potential expansion so we don't need to modify it every time we add a new rack 
[11:25:38] <claime>	 tappof: can i merge your slothslos puppet change?
[11:26:23] <tappof>	 claime: just a sec
[11:26:28] <claime>	 ack
[11:28:42] <tappof>	 yes claime thx
[11:30:47] <claime>	 {{done}}
[12:58:04] <topranks>	 btullis: yeah, I added you to that task 
[12:58:09] <topranks>	 patch even 
[12:58:48] <topranks>	 but TL;DR I didn't do what I intended.  there is a need to exclude analytics and cloud ranges from those lists, which means no matter what way you slice it the list is verbose (at least in eqiad/codfw)
[12:59:14] <topranks>	 it seemed cleaner to keep the current "list every vlan" approach than start aggregating just to save the odd line 
[12:59:36] <topranks>	 I have pre-allocated the ranges for our upcoming work in eqiad, which should be the last of these we add unless we expand our footprint