[08:30:28] <klausman>	 "Fixed the nit by switching to PHP. Merged."
[13:24:55] <topranks>	 folks I'm gonna step away for a bit and put my head down
[13:25:12] <topranks>	 not feeling very good, my other hald has tested positive for the virus so hoping it's not that
[13:25:24] <topranks>	 with any luck back at full strength Monday
[13:25:38] <topranks>	 s/hald/half
[13:26:17] <godog>	 topranks: take care! yeah rest is good and good luck
[13:26:24] <XioNoX>	 topranks: rest well!
[13:30:45] <moritzm>	 take care and good luck with the rest!
[13:30:53] <sukhe>	 topranks: good luck, be well!
[13:30:58] <moritzm>	 rest/test :-)
[13:44:03] <jbond>	 topranks: take care 
[13:49:18] <arturo>	 topranks: <3
[14:10:49] <cdanis>	 topranks: rest up and good luck <3
[16:38:27] <Krinkle>	 I'm looking at speeding up the coverme.toolforge downloads of large files from https://performance.wikimedia.org/arclamp/logs/daily/
[16:38:34] <Krinkle>	 it seems curl/guzzle php won't use compression there
[16:38:39] <Krinkle>	 https://performance.wikimedia.org/arclamp/logs/daily/2022-03-03.excimer-wall.load.log
[16:38:55] <Krinkle>	 using curl directly on the CLI seems to confirm this, so I'm guessing it's not an issue with the client sending accept-encoding headers
[16:40:20] <Krinkle>	 I tried both with `Accept-Encoding: gzip` and with `accept-encoding: deflate, gzip, br, zstd` but no dice
[16:40:43] <Krinkle>	 it's a cache hit in varnish though, so maybe there's something special for this backend preventing it from using compression
[17:14:16] * dcaro off
[17:38:35] <btullis>	 Quick question. I have allocated a new service IP for LVS in Netbox: re: https://phabricator.wikimedia.org/T301458#7753703 and https://netbox.wikimedia.org/ipam/ip-addresses/10434/
[17:39:10] <btullis>	 But I haven't yet run the Update generated records cookbook mentioned here: https://wikitech.wikimedia.org/wiki/DNS/Netbox#Update_generated_records
[17:39:48] <btullis>	 Is this best left to Monday, or is it the sort of think that I should always do immediately after changes are made to Netbox?
[17:46:28] <XioNoX>	 btullis: better run it now
[17:46:53] <btullis>	 XioNoX: Thanks.
[17:47:00] <XioNoX>	 btullis: otherwise icinga will alert about discrepancy between DNS and netbox
[17:47:46] <XioNoX>	 btullis: that's only if the "DNS name" field is set though
[17:49:02] <btullis>	 Gotcha. Yes the DNS name field is set to datahubsearch.svc.eqiad.wmnet
[17:49:30] <XioNoX>	 btullis: and as point #11 says, it's actually not used in prod, so running the dns cookbook is effectively a noop
[17:51:40] <btullis>	 Ah, got it.
[17:51:47] <XioNoX>	 btullis: also, as the doc is not really clear: "If this is a VIP, make sure you get the same last octect in both eqiad and codfw datacentres" means, create "10.2.1.71/32" as "reserved" in Netbox, so if one day the service needs to be added to codfw, it will use the same last octet
[17:52:47] <btullis>	 Oh OK. Will do. Ta.
[19:17:07] <volans|off>	 btullis: just one nit, https://netbox.wikimedia.org/ipam/ip-addresses/10435/ should be /32
[19:18:56] <volans|off>	 I'm editing it right now
[19:19:20] <volans|off>	 {done}
[20:04:14] <btullis>	 Ah, thanks vol.ans. Much appreciated.