[01:46:57] <paladox>	 bd808 i got it some what working now!
[01:47:39] <paladox>	 (auto provisions a gerrit install, i just need to fix the systemd unit, apparently it's not finding java_options thus is companing about java.options.each being nil)
[02:05:15] <bd808>	 paladox: ah. I know the problem that your hitting with the erb template! Puppet 4's scope rules won't pass your variable through to the define's code. The fix is to use an epp template and explicitly pass the variable through. Here's an example -- https://github.com/wikimedia/mediawiki-vagrant/blob/57ef729a34620611b170d88d56afc337f0813290/puppet/modules/thumbor/manifests/service.pp#L30-L52
[02:05:34] <paladox>	 bd808 ah! (thanks!!)
[02:13:41] <paladox>	 bd808 works now!
[02:15:21] <bd808>	 paladox: cool. I'll try to make some time tomorrow or over the weekend to test it out
[02:15:30] <paladox>	 thanks :)
[02:15:44] <paladox>	 im just trying to figure out how to stop it provisioning gerrit after it's done it.
[02:20:06] <bd808>	 paladox: what part of it is happening again on a second puppet run?
[02:20:20] <paladox>	 both install_gerrit and reindex_gerrit
[02:20:24] <paladox>	 i think i know why
[02:21:52] <bd808>	 hmmm... file paths wrong for the 'creates' attributes you added?
[02:22:43] <paladox>	 fixed now :)
[02:22:54] <paladox>	 needed a test ! -f <file> rather then test -e <file>
[02:23:29] <paladox>	 published new change :)
[02:48:45] <paladox>	 bd808 https://gerrit-gitldap.wmflabs.org/r/#/q/status:open works!
[10:33:15] <kiwi_22>	 There's a bit of a critical issue with the Quickstatements batch list - normally up to 16 batches can run simultaneously, but right now there's just 1 that's running, everything else with any "DONE" items on the list at https://tools.wmflabs.org/quickstatements/#/batches was last updated almost 2 hours ago.
[10:33:23] <kiwi_22>	 Is everything else in Toolforge running properly?
[12:35:29] <arturo>	 !log tools.quickstatements stop webservice
[12:35:30] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickstatements/SAL
[16:57:06] <wm-bot>	 !log tools.quickcategories <lucaswerkmeister> deployed 3c58cc0810 (minor UI improvements)
[16:57:08] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL
[18:01:06] <ragesoss>	 Some recent revisions in Replica — particularly for wikidata — don't seem to have rev_user_text or rev_user fields set. Is that an expected thing as part of the actor table stuff?
[18:05:37] <ragesoss>	 bstorm_: ^
[18:06:31] <bstorm_>	 ragesoss: *I* am not removing them on the replica views until Monday.  They will error right out after that.  If the data is not in them, that'd be upstream
[18:07:47] <bstorm_>	 Hmm, actually, the recent changes we did for that table to speed up the rev_actor field could have affected it a bit.  In general, at this point, I'd recommend not using those fields at all.  You'll get an error after the changes start Monday
[18:08:05] <bstorm_>	 only the much slower _compat tables will retain them
[18:08:25] <bstorm_>	 Everything should be backfilled to the actor storage
[18:10:59] <ragesoss>	 yeah, these missing values are happening for last two days of wikidata, but not for en.wiki, so I guess it's some upstream thing with wikidata replication.
[18:11:02] <ragesoss>	 :/
[18:14:44] <ragesoss>	 bstorm_: I'm using revision_userindex.rev_user and .rev_user_text. Are those going away?
[18:14:51] <bstorm_>	 Yes
[18:14:53] <ragesoss>	 or just revision.rev_user
[18:14:57] <bstorm_>	 both
[18:15:10] <bstorm_>	 you have to use revision.rev_actor and data from the actor table
[18:16:17] <bstorm_>	 T223406
[18:16:18] <stashbot>	 T223406: Remove reference to fields replaced by the actor table from WMCS views - https://phabricator.wikimedia.org/T223406
[18:16:38] <bstorm_>	 That provides a bit more context, ragesoss
[18:16:47] <bstorm_>	 Also the linked tasks might help
[18:17:58] <ragesoss>	 thanks. didn't realize this affected revision_userindex in addition to revision.
[18:19:59] <bstorm_>	 revision_userindex is a view of the revision table that takes advantage of another index a bit better.
[18:20:16] <bstorm_>	 But yeah, the only tables that won't be affected are like revision_compat
[18:20:29] <bstorm_>	 However, I expect those to be slow as well
[18:26:31] <zhuyifei1999_>	 bstorm_: the scratch mount on encoding01.video.eqiad.wmflabs is read-only. can I remount it read-write, considering your emails regarding scratch is 3 days ago?
[18:26:56] <bstorm_>	 uhhh...I may have set something incorrectly in my patch
[18:27:04] <bstorm_>	 You should be able to.  Checking
[18:27:23] <zhuyifei1999_>	 ok I'll wait for you to check. I don't want to mess up :P
[18:28:16] <bstorm_>	 Yes, I screwed that up.  My apologies.  Putting up the patch to fix now
[18:30:34] <bstorm_>	 https://gerrit.wikimedia.org/r/c/operations/puppet/+/513666
[18:31:10] <bstorm_>	 Going to merge right away and see if that fixes it.  It should!
[18:31:37] <ragesoss>	 thanks much bstorm_! I think we've nearly got our tool sorted out, and actor had the usernames that disappeared for recent wikidata revisions.
[18:33:43] <bstorm_>	 Good :)
[18:35:45] <bstorm_>	 zhuyifei1999_: the puppet change I put up seems to be mounting rw correctly now
[18:36:13] <bstorm_>	 Whenever the change hits your server...
[18:39:14] <bennofs[m]>	 are the `.out` and `.err` files updated continuously or only at the end of a job run?
[18:39:37] <zhuyifei1999_>	 bstorm_: thanks ;)
[18:39:55] <bstorm_>	 Thank you!  Everyone missed that on code review
[18:40:43] <bstorm_>	 bennofs[m]:  Continuously appears to be the usual behavior
[18:44:18] <bennofs[m]>	 cool, thanks! one more question: do grid engine jobs have access to more than a single core? (i.e, does it make sense to parallelize my code?)
[18:45:17] <lucaswerkmeister>	 $ jsub -sync y nproc
[18:45:21] <lucaswerkmeister>	 $ cat ~/nproc.out
[18:45:23] <lucaswerkmeister>	 4
[18:46:16] <lucaswerkmeister>	 if it’s an easily parallelizable workload, I guess it could make sense
[19:11:20] <bd808>	 bennofs[m]: each grid engine exec node has 4 cores and grid engine doesn't apply any cgroups or other restrictions that would prevent you from using multiple cores, but ... using more than one core heavily for a long time might starve out other jobs scheduled on the same node.
[19:11:35] <bd808>	 so I guess experiment, but be careful :)
[19:13:20] <bd808>	 the lack of cgroup restrictions on grid jobs is one of the things I dislike about grid engine generally. The service expects everyone to be nice and play well with others, which is an easy social contract to break accidentally (and on purpose)
[22:06:20] <wm-bot>	 !log tools.quickcategories <lucaswerkmeister> deployed ebfed74416 (minor error handling improvements)
[22:06:22] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL
[22:59:40] <bd808>	 !log automation-framework Increased quota for cores, ram, and instances (T224057)
[22:59:42] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Automation-framework/SAL
[22:59:43] <stashbot>	 T224057: Request increased quota for Automation Framework Cloud VPS project - https://phabricator.wikimedia.org/T224057
[23:07:01] <bd808>	 !log sso Increased quota for floating ips (T224272)
[23:07:03] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Sso/SAL
[23:07:04] <stashbot>	 T224272: Request increased quota for sso Cloud VPS project - https://phabricator.wikimedia.org/T224272