[10:13:24] <dcausse>	 lunch
[12:56:26] <inflatador>	 <o/
[12:57:44] <dcausse>	 o/
[13:11:00] <pfischer>	 o/
[13:11:14] <pfischer>	 errands, back in 1h
[14:06:39] <inflatador>	 dcausse are you still in the Flink mtg? Sorry, I was kinda lost there. Hit me up if/when you wanna pair
[14:07:12] <dcausse>	 inflatador: sure I'd love to ship a couple patches if you're ok?
[14:11:01] <Trey314159>	 Hey all—should we cancel today's retro since our RetroMeister is on vacation?
[14:17:26] <inflatador>	 Works for me
[14:17:48] <dcausse>	 fine by me
[14:20:03] <ottomata>	 dcausse: re https://phabricator.wikimedia.org/T334244, any reason not to 1.17 ?
[14:20:37] <dcausse>	 ottomata: I'd like to avoid a big jump from 1.12 to 1.17
[14:20:46] <dcausse>	 for the production job
[14:20:53] <ottomata>	 heh, you are already at 1.16 and that is big enough for ya? :)
[14:21:03] <ottomata>	 k
[14:21:20] <ottomata>	 added a comment, i can merge build after that, but maybe inflatador  wants to? :)
[14:21:22] <dcausse>	 we're running 1.16 on the operator with a dedicated branch
[14:21:41] <dcausse>	 ottomata: thanks!
[14:22:40] <dcausse>	 and 1.17 deprecates all scala apis apparently :(
[14:34:25] <inflatador>	 ottomata yes, we'll take on that work...I could use the practice ;)
[14:40:02] <ottomata>	 dcausse:  i thought all scala apis were kinda gone anyway?
[14:40:18] <ottomata>	 k inflatador i'll let you merge and build then :)
[14:40:19] <ottomata>	 ty!
[14:42:47] <dcausse>	 yes but I somehow hoped that scala removal would not happen so quicly :)
[14:56:28] <ebernhardson>	 \o
[14:57:06] <inflatador>	 <o/
[15:04:53] <dcausse>	 o/
[15:27:08] <inflatador>	 ottomata dcausse new flink image is built/published
[15:27:23] <dcausse>	 thanks!
[15:55:55] <inflatador>	 workout, back in ~40
[16:43:50] <inflatador>	 back
[17:31:31] <ebernhardson>	 huh, turns out php >= 8.1.0 now encodes ' in htmlspecialchars. breaks one of our integration tests :P
[18:12:30] <inflatador>	 looks like we already lost one of our flink task mgr pods ;(
[18:14:39] <dcausse>	 yes... trying disabling jemalloc, next step would perhaps be to reenable it and use it to trace jvm mem allocation
[18:14:57] <dcausse>	 smth like https://www.evanjones.ca/java-native-leak-bug.html
[18:29:49] <inflatador>	 dcausse should we revert https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/907934 before merging the jemalloc patch?
[18:31:08] <dcausse>	 we could but rocksdb metrics are useful tho
[18:34:38] <inflatador>	 dcausse I'll just merge/deploy the jemalloc patch on top then...was going to do that right now unless you think I should wait
[18:35:44] <dcausse>	 inflatador: I tried to deploy it but the syntax was incorrect
[18:35:58] <dcausse>	 shipping https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/908611 to fix
[18:36:10] <dcausse>	 inflatador: feel free to deploy it once it's merged
[18:36:17] <inflatador>	 dcausse will do
[18:36:21] <dcausse>	 thanks!
[18:46:49] <dcausse>	 deployed, wanted to see if the shape is widely different before going offline
[19:01:24] <dcausse>	 usage is very different indeed... the java process uses 50% less mem on startup with glibc than with jemalloc 5.1...
[19:02:31] <dcausse>	 does not mean that there's no leak with glibc but it's surprising that the difference is so huge
[19:02:35] <dcausse>	 dinner