[08:40:16] <gehel>	 zpapierski: meeting?
[08:42:57] <zpapierski>	 Ah forgot to cancel - I'm off today, sorry! 
[08:43:11] <gehel>	 my bad! Get away from IRC!
[08:45:29] <zpapierski>	 Aren't you off today, too? 
[08:45:41] <gehel>	 nope, not me
[09:39:59] <gehel>	 lunch + Oscar's school
[09:50:26] <dcausse>	 errand+lunch
[13:37:55] <mpham>	 dcausse: is https://phabricator.wikimedia.org/T284040 part of the wcqs productionization epic?
[13:39:18] <dcausse>	 mpham: not sure
[13:39:33] <dcausse>	 more under T244341
[13:39:34] <stashbot>	 T244341: Stop using blank nodes for encoding SomeValue and OWL constraints in WDQS - https://phabricator.wikimedia.org/T244341
[13:40:48] <mpham>	 i thought that the blank nodes skolemization we did for the WDQS streaming updater was necessary for getting wcqs into production as well
[13:41:43] <dcausse>	 it will indeed, enabling the new updater will de-facto enable this feature
[13:42:09] <dcausse>	 here it's more to force-enable the skolemization before having the new updater for wcqs in place
[13:45:32] <dcausse>	 mpham: I'm fine to put it under "wcqs productionization epic" but just that it might have more value than just "wcqs" (give tools/processes/community members more chances to test the blank skolemization)
[13:46:24] <mpham>	 it sounded like it could be useful for wdqs users to test it out as well?
[13:47:30] <dcausse>	 wdqs users can test this with query-preview, I followed a suggestion made here: https://phabricator.wikimedia.org/T266470#7122945
[13:50:12] <mpham>	 sorry, maybe I missed what the beyond wcqs value is, if wdqs users are able to test this somewhere else
[13:54:11] <dcausse>	 I guess that it's to "increase the chances" to catch a possible problems related to this, ideally you're right query-preview has been exposed for that purpose
[13:55:03] <dcausse>	 errand
[13:56:27] <mpham>	 Ok, thanks for the explanation. I'll put it under the wcqs epic then
[14:39:21] <dcausse>	 errand 2
[14:56:54] <ebernhardson>	 \o
[14:59:41] <dcausse>	 o/
[15:01:43] <gehel>	 swimming pool accident with the kids (not too bad, but enough for a run to the hospital)
[15:01:52] <gehel>	 I'll ge and help manage the kids!
[15:02:46] <dcausse>	 ouch, take care!
[15:16:31] <ryankemper>	 oof! hope things go smoothly, hospital trips are never fun :(
[15:28:52] <gehel>	 Oscar loooves hospitals ! But maybe not this time ;)
[15:29:28] <gehel>	 ebernhardson: I had a look at that sonarqube issue with hashar. But we did not have time to test and deploy yet.
[15:29:40] <gehel>	 Maybe you could have another look with him ?
[15:43:58] <ebernhardson>	 gehel: sure i can look it over
[15:52:37] <gehel>	 ebernhardson: it should just need deployment and testing on both a patch and a post merge builds
[16:50:59] <dcausse>	 dinner
[17:04:32] <elukey>	 ebernhardson: o/ not sure if you saw my msg over the weekend (it was for the chan) but I had to run apt-get clean on an-airflow1001 since the root partition was getting full
[17:05:06] <elukey>	 I don't recall how/when we drop logs in there, but it might be good to review it before the partitions fills up again
[17:05:14] <elukey>	 Cc: ryankemper: --^ :_
[17:05:15] <elukey>	 :)
[17:05:20] <ebernhardson>	 elukey: hmm, it filled last week so i dropped ~6G of logs
[17:05:38] <elukey>	 it reached 94% when I checked it
[17:05:49] <elukey>	 and it went down to 84% after my cleanu
[17:05:51] <elukey>	 *cleanup
[17:06:10] <elukey>	 (I didn't want to drop any log without your team's green light)
[17:06:19] <ebernhardson>	 hmm, not sure what to do with that longer term. Will have to ponder. The ticket i made is T283856
[17:06:20] <stashbot>	 T283856: Airflow filled disks after losing connection to sql server - https://phabricator.wikimedia.org/T283856
[17:14:16] * ebernhardson is never sure anymore if a 'remember me' checkbox is going to keep me logged in, or just pre-fill the username in the form
[17:16:20] <elukey>	 I'll cross-post this to #analytics since Andrew is working on Airflow in hadoop test
[17:32:12] <ryankemper>	 elukey: not related to airflow but while you're around, I wanted to ask about the wdqs / pybal page over the weekend
[17:32:28] <ryankemper>	 from what I gather, is setting `pooled=inactive` better than `pooled=no` as far as pybal is concerned?
[17:32:45] <ryankemper>	 like does the inactive node not count as depooled as far as the logic of "can pybal afford to depool a node" goes?
[17:33:12] <elukey>	 yes exactly! 
[17:33:30] <elukey>	 I always forget too, it is easy to miss
[17:33:43] <ryankemper>	 ack!
[17:34:04] <elukey>	 pooled=no is still ok for temporary things etc..
[17:34:24] <elukey>	 but if a node is down for a long period of time, inactive is best so pybal doesn't count it
[18:44:39] * ebernhardson reads the wellness guidelines and wonders if he should just submit the full thing under food reimbursement...Averages to 6.25 days a month which i'm sure i've done
[18:47:49] <ebernhardson>	 aww, actually it's supposed to be only for things that usually would have provided in-person food. Not going to hit the limit on that :) 
[19:50:06] <ryankemper>	 Gym, back in 1hr
[21:17:44] <ebernhardson>	 ryankemper: how goes everything this week
[22:47:17] <ryankemper>	 whoops had irccloud closed
[22:47:36] <ryankemper>	 ebernhardson: great, j.bond and I synced today and were able to figure out how to unblock the wdqs reimage
[22:47:59] <ryankemper>	 m.oritzm is gonna do some reviewing to make sure we can deploy the fix for all hosts and not just wdqs so we should be able to start reimaging the downed nodes tomorrow