[07:46:40] <elukey>	 hello folks
[07:47:07] <elukey>	 qq - I noticed wcqs1003 not pooled and failing pybal health checks, is it expected? (Didn't find anything in the SAL)
[07:47:14] <elukey>	 inflatador: o/ --^ 
[08:05:09] <dcausse>	 elukey: o/ might be related to T316236
[08:05:10] <stashbot>	 T316236: Reload WCQS from dumps - https://phabricator.wikimedia.org/T316236
[08:06:28] <elukey>	 ah ack thanks :)
[10:11:11] <gehel>	 dcausse, pfischer_ : I'm proposing to relax the checkstyle rule for generics type names a bit: https://gerrit.wikimedia.org/r/c/wikimedia/discovery/discovery-maven-tool-configs/+/853932
[10:11:38] <dcausse>	 +1
[10:11:43] <gehel>	 in particular to avoid https://integration.wikimedia.org/ci/job/search-extra-maven-java8-docker/291/console
[10:18:36] <dcausse>	 gehel: might be nice if possible to allow snake case method names for unit tests
[10:19:01] <dcausse>	 e.g. https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/853366/1/streaming-updater-consumer/src/test/java/org/wikidata/query/rdf/updater/consumer/UpdatePatchAccumulatorUnitTest.java
[10:19:23] <dcausse>	 snake case is more readable imo here
[10:20:55] <pfischer_>	 +1
[10:59:44] <gehel>	 not sure how to tell that to checkstyle. Maybe a suppression for all files matching Test* / *Test? That would completely disable the check, but that's probably better than a check that gets in our way.
[11:00:40] <dcausse>	 pfischer_: regarding schemas I'm going to the one related to T317609 under jsonschema/cirrussearch/update_pipeline in 
[11:00:41] <stashbot>	 T317609: Create a schema for fetch failures - https://phabricator.wikimedia.org/T317609
[11:01:20] <dcausse>	 https://gerrit.wikimedia.org/r/admin/repos/schemas/event/primary
[11:01:39] <dcausse>	 meh, can't type
[11:02:23] <dcausse>	 take 2: regarding schemas I'm going to add the one related to T317609 under jsonschema/cirrussearch/update_pipeline in the repo https://gerrit.wikimedia.org/r/admin/repos/schemas/event/primary
[11:02:59] <dcausse>	 gehel: or we allow '_[a-z]' in method names everywhere?
[11:04:18] <dcausse>	 gehel: when you say "disable the check" it's disabling all checkstyle?
[11:05:16] <gehel>	 no, only disable that single check "MethodName" https://checkstyle.sourceforge.io/config_naming.html#MethodName
[11:05:26] <gehel>	 Or provide another regex?
[11:06:04] <dcausse>	 if it's only disabling MethodName I'm all for it unless I'm missing something
[11:07:19] <dcausse>	 lunch
[11:08:04] <gehel>	 it would mean that any method name is allowed for tests, but I'm OK with that. Or allowing "_" in all methods, which would look weird in non test classes, but weird enough that we would most probably never even try to write such method names.
[11:14:30] <gehel>	 dcausse, pfischer_ : https://gerrit.wikimedia.org/r/c/wikimedia/discovery/discovery-maven-tool-configs/+/853942 (and follow up cleanup)
[11:14:53] <gehel>	 lunch
[13:12:50] <gehel>	 dcausse: while you're at it, easy review at https://gerrit.wikimedia.org/r/c/wikimedia/discovery/discovery-parent-pom/+/854000
[14:33:35] <gehel>	 dcausse: I've added a few comments and fixed most of them already: https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/853366
[14:34:23] <gehel>	 a second pass from your eyes would be welcomed
[14:35:06] <dcausse>	 sure, looking
[14:41:00] <inflatador>	 <o/
[14:43:18] <dcausse>	 o/
[14:43:47] <gehel>	 o/
[14:56:25] <inflatador>	 FWiW, looks like there's been a new Blazegraph commit for the first time in awhile: https://github.com/blazegraph/database/commit/829ce8241ec29fddf7c893f431b57c8cf4221baf 
[15:43:58] <ebernhardson>	 \o
[15:49:13] <gehel>	 inflatador, ryankemper: is it expected that elastic2049 is a spare system? Is it following a hardware issue and waiting to be reconfigured? https://github.com/wikimedia/puppet/blob/production/manifests/site.pp#L1096-L1098
[15:50:52] <inflatador>	 gehel :eyes
[15:51:30] <dcausse>	 o/
[15:52:46] <inflatador>	 <o/
[15:53:05] <volans>	 inflatador: re: T321605 FYI expect the rsync approach to be potentially slower than the nc one
[15:53:05] <stashbot>	 T321605: Make WCQS/WDQS data transfer cookbook more reliable  - https://phabricator.wikimedia.org/T321605
[15:54:09] <inflatador>	 volans ACK, I think we are going to try reliability over speed as we have a very low success rate with the current approach
[15:54:43] <inflatador>	 gehel elastic2049 has been decommed in https://phabricator.wikimedia.org/T313842 , I guess our next step is to remove it from site.pp entirely?
[15:54:45] <volans>	 ack, sorry for the out of the blue comment, I don't have time to dig into this, but would be nice to understand what's causing it
[15:56:17] <inflatador>	 Agreed. We'll probably revisit in the future. I've seen that pigz -nc - openssl approach used successfully in the past
[15:57:45] <volans>	 it's what transfer.py uses too
[15:57:47] <volans>	 fwiw
[15:58:10] <volans>	 https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/transferpy/+/refs/heads/master/transferpy/Transferer.py#218
[16:00:13] <inflatador>	 Oh yeah, that's exactly what we used to do for MySQL....xtrabackup or LVM snapshot + nc & friends
[16:01:58] <gehel>	 Trey314159: triage meeting: https://meet.google.com/eki-rafx-cxi
[16:02:14] <gehel>	 Oh, sorry, you're out
[17:05:51] <ebernhardson>	 i dont remember, do operations/alerts patches get auto-deployed?
[17:09:27] <godog>	 they do, max 30 min at the next puppet run
[17:09:46] <godog>	 ebernhardson: ^
[17:09:57] <ebernhardson>	 godog: cool, thanks!
[17:10:18] <godog>	 np!
[17:10:24] <ebernhardson>	 godog: i was expecting to see that somewhere in https://wikitech.wikimedia.org/wiki/Alertmanager but didn't
[17:11:26] <godog>	 yeah fair enough, it is in alerts.git's README but not there indeed
[17:11:45] <ebernhardson>	 ahh, i suppose that would have made sense to check. didn't occur to me
[17:13:12] <godog>	 a good question nevertheless, I'll drop it in the FAQ 
[17:16:00] <dcausse>	 dinner
[18:06:59] <inflatador>	 lunch/errand, back in ~1h
[19:06:27] <inflatador>	 back