[07:14:35] <pfischer>	 O/
[07:22:15] <dcausse>	 o/
[07:22:59] <dcausse>	 pfischer: welcome back! let me know if/when you have a couple minutes for a quick chat
[07:35:06] <pfischer>	 dcausse: Sure, let me clear my in inbox and I’ll get back to you in 10-15 min.
[07:35:19] <dcausse>	 sure, no rush
[10:27:48] <dcausse>	 lunch
[13:05:15] <inflatador>	 <o/
[13:11:17] <dcausse>	 o/
[15:19:11] <ebernhardson>	 \o
[15:21:46] <dcausse>	 o/
[15:30:54] <pfischer>	 o/
[15:33:50] <pfischer>	 dcausse: I’m looking at the rdf-streaming-updater blubber descriptor (https://gitlab.wikimedia.org/repos/search-platform/flink-rdf-streaming-updater/-/tree/main) an try to figure out why you copy test-log4j-console.properties to conf/log4j-console.properties. I can’t find any reference to this path in the rdf code (https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/rdf/+/refs/heads/master). Is that file 
[15:33:50] <pfischer>	 picked up by convention and if so: What’s the convention?
[15:36:22] <dcausse>	 pfischer: it's erasing the default flink one and then will be used by the test that runs "/opt/flink/bin/standalone-job.sh start-foreground"
[15:36:56] <dcausse>	 start-foreground implies that flink will use the log4j-console.properties file
[15:37:59] <dcausse>	 I don't remember why I've overridden the log4j config provided by flink by default tho
[15:37:59] <pfischer>	 Okay, so that’s for flink’s logging. Does it bother if the application to be launched uses log4j2?
[15:39:36] <dcausse>	 hm... I guess what we want if the app to integrate with flink logger so that we write to the same channel (in k8s logs are collectect via stdout)
[15:39:59] <dcausse>	 do we use log4j2 directly or slf4g?
[15:40:04] <dcausse>	 slf4j*
[15:40:46] <pfischer>	 The cirrus-streaming-updater uses log4j2 through slf4j
[15:41:51] <dcausse>	 flink should be using log4j2 so test-log4j-console.properties is actually used by log4j2
[15:42:57] <dcausse>	 ah perhaps I added that test-log4j to make sure that the ECS layout was working
[15:43:40] <pfischer>	 Okay, thanks. I’ll reuse that for now. Lets see what happens…
[16:13:50] <inflatador>	 working out, back in ~40
[16:49:46] <ebernhardson>	 hmm, wonder if i'm on the wrong images...docker-registry.wikimedia.org/dev/buster-php81-fpm should be it, but has composer 1.10 instead of 2.x
[16:50:24] <inflatador>	 back
[16:53:11] <dcausse>	 ebernhardson: weird, I have docker-registry.wikimedia.org/dev/buster-php81-fpm:1.0.0 too but composer reports Composer version 2.3.3 2022-04-01 22:15:35
[16:53:40] <dcausse>	 perhaps you've built that image locally in the past?
[16:55:38] <ebernhardson>	 hmm, maybe. I'll try deleting and re-pulling the image
[16:59:28] <ebernhardson>	 hmm, indeed starting the image directly i get composer 2, it seems mwcli is starting php74-fpm and not php81-fpm for some reason
[17:07:34] <ebernhardson>	 and the reason is...i'm an idiot :P  I used `MEDIAWIKI_IMAGE="${MEDIAWIKI_IMAGE:-docker-registry.wikimedia.org/dev/buster-php81-fpm:1.0.0}"` since i'm writing a shell script, and pasting that into my shell just keeps the existing value
[17:09:59] <dcausse>	 :)
[17:17:46] <dcausse>	 dinner
[17:37:30] <inflatador>	 lunch, back in ~45
[18:09:01] <inflatador>	 back
[18:13:54] <ryankemper>	 Might be 5’ late to pairing
[21:21:12] <inflatador>	 anyone have any objections to setting Data Engineering as the point of contact for airflow hosts? https://phabricator.wikimedia.org/T334522 
[21:21:22] <inflatador>	 gehel ^^ Steve wanted me to ask you on that one too
[21:21:59] <ebernhardson>	 seems fine
[21:22:06] <gehel>	 No objections, quite the opposite!
[21:22:29] <inflatador>	 cool, will get a patch started then
[22:19:15] * ebernhardson finds it mildly funny the test suite is trying to upoad No_SVG.svg, and the default mwdd config is failing it with filetype-banned