[10:36:53] <dcausse>	 scanned the mjolnir feature selection job logs that failed and finally found: "Total size of serialized results of 10 tasks (2.1 GiB) is bigger than spark.driver.maxResultSize (2.0 GiB)"
[10:43:18] <dcausse>	 might be that this job is pulling a lot of data into the driver?
[10:44:06] <dcausse>	 should we simply bump spark.driver.maxResultSize a bit?
[11:11:30] <dcausse>	 pushed https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/merge_requests/588, seen other jobs with spark.driver.maxResultSize=8g so 3g might still be acceptable
[11:31:23] <dcausse>	 lunch
[14:01:18] <gehel>	 inflatador: are T351354 and T353878 in progress? If so, could you move them to the right column on our workboad?
[14:01:18] <stashbot>	 T351354: Service implementation for cloudelastic1007-1010 - https://phabricator.wikimedia.org/T351354
[14:01:19] <stashbot>	 T353878: Service implementation for elastic2087-2109 - https://phabricator.wikimedia.org/T353878
[14:13:53] <inflatador>	 gehel ACK, will do
[14:13:54] <inflatador>	 <o/
[15:11:57] <dcausse>	 o/
[15:53:42] <ebernhardson>	 \o
[15:53:53] <ebernhardson>	 dcausse: hmm, yea we can increase that and see how it goes
[15:54:04] <dcausse>	 o/
[15:54:30] <dcausse>	 ok will merge & deploy
[16:44:01] <ryankemper>	 We ended up moving the deploying the new cergen cert to collaboration service's office hours tomorrow
[16:44:16] <ryankemper>	 So in about 24h we should have the graph split initial operational work done
[16:45:30] <dr0ptp4kt>	 nice ryankemper!
[16:45:37] <dcausse>	 ryankemper: nice!
[16:49:37] <ebernhardson>	 if you ever feel like we move too slow...remember nasa landed an asteroid sample return last september, and they finally finished opening it 3 months later
[16:51:00] <dcausse>	 lol
[16:52:35] <dcausse>	 cleared last mjolnir run to see if it passes now
[16:52:55] <dcausse>	 need prepare dinner, back later tonight
[16:53:42] <ebernhardson>	 kk, thanks!
[18:00:24] <inflatador>	 lunch, back in ~1h
[18:59:04] <ebernhardson>	 apparently flink has something called fine grained resource management. In theory we could define a resource that has N available http request slots and flink will handle ensuring the global limit is respected. But looks a bit complicated, and might have issues with the ordering requirement
[19:00:10] <ebernhardson>	 also it might not be as amicable to our needs, it's use case is slightly different
[19:13:54] <inflatador>	 sorry, been back
[19:38:57] <ebernhardson>	 random fun command: cd $(dirname !$)
[21:16:45] <dr0ptp4kt>	 ebernhardson: ha