[00:22:45] Wow /data/scratch is so much faster! [00:23:04] Reedy: Less than a second to count the lines!!!!!! [00:23:11] mzmcbride@tools-sgebastion-07:~/scripts/enwiki$ time wc -l /data/scratch/enwiki-namespace-0-redirects-2019-06-03.txt [00:23:18] 8890599 /data/scratch/enwiki-namespace-0-redirects-2019-06-03.txt [00:23:27] real 0m0.914s [00:24:08] Bless you all. [00:24:10] You do realise that WMCS is free and not a paid subscription? (hence why you will see more slowness then paying :)) [00:25:02] Someone was snarking as I left. [00:25:04] So I'm back. [00:26:04] paladox: There are many definitions of free and you're only discussing one specific kind. [00:26:19] What other definition are there? [00:26:50] paladox: https://en.wiktionary.org/wiki/free#English [00:27:17] Using volunteer time is not really free. [00:27:26] Nor is services :) [00:27:43] Weren't you just saying they were free? [00:27:49] Now you're saying the opposite? [00:27:54] No, i said free for us [00:28:09] Right, you're only focused on money paid directly out of pocket. [00:28:18] And that discounts all the other costs. [00:28:19] Such as time. [00:29:06] time is not a factor as volunteer means choice. [00:29:41] Time is our most precious resource. [00:29:57] Which is your choice [00:30:07] What a toxic view. [00:30:11] the WMF are not forcing you to volunteer for them. [00:30:26] Yeah, that was the same nonsense Reedy was pushing earlier. [00:30:39] That's a toxic and shitty argument that you all should avoid. [00:30:45] Marybelle: Language [00:30:47] Toxic? [00:31:18] Reedy: If you have feedback, you can use more than a single noun. [00:32:00] paladox: Yeah, it's pretty toxic to suggest that people have to tolerate poor performance and services because you're only wasting their time. [00:32:24] And when someone mentions that, it's pretty toxic to suggest that the alternative is doing something else. [00:32:36] That's pretty much the definition of a toxic environment. [00:32:45] And Reedy's CONCERN-TROLLING about language doesn't mask that. [00:32:59] Well i think the WMCS team do a good job. And as Reedy said earlier you get what you payed for. [00:33:26] Marybelle reedy is not trolling fyi. [00:33:32] Yes he is. [00:33:45] He's not? [00:35:17] He said "language" as this channel is a professional place, not a place for you to start swearing. [00:35:38] paladox: Do you work? [00:35:42] no? [00:35:47] why do you ask? [00:35:51] Then what do you know about professional places? [00:36:03] Are you seriously kidding me? [00:36:42] I'm not allowing this place to drain more of my time and energy today. [00:36:55] Cut it out [00:36:58] I only re-joined because I didn't realize it was you so made the snarky comment. [00:37:10] This discussion is not helping anyone [00:37:10] Krenair: Hush. [00:37:56] Unlike opping as a threat. [00:37:59] There is no need to treat each other like this [00:38:02] Buncha nonsense. [00:38:18] Per Krenair [00:38:54] Krenair: I explained above why I think several people in here are creating a toxic environment for volunteers. [00:39:13] huh [00:39:15] And it's baffling that you're enabling them, but whatever. [00:41:39] paladox, there was no need to drag the chat back to that subject after he just came in to say data/scratch was working ok [00:41:55] ok. [00:56:00] *sigh* I turn my back and y'all start going at each other again. :/ [00:57:30] For what it is worth, MZ (Marybelle) has a point about gratis cost of our services to our users not being a valid reason for things being slow or broken. [00:57:59] but really, y'all don't provoke each other for amusement [08:56:52] !log integration reallocating integration-slave-docker-1059 and integration-slave-docker-1058 to cloudvirt1012 (T223971) [08:56:57] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Integration/SAL [08:56:59] T223971: Old cloudvirt (with Intel Xeon) are twice slower than new ones (Intel Sky Lake) - https://phabricator.wikimedia.org/T223971 [10:42:27] is the hardware of different SGE executor nodes different or are they all the same except for different load? [10:43:09] bennofs[m]: yes, SGE exec nodes are mostly the same. Different load, yes [10:43:18] more info here https://tools.wmflabs.org/openstack-browser/project/tools bennofs[m] [12:53:53] !log wikidata-dev wikidata-new-wbterm sudo find -$ -type d -o -type f -$ -exec chmod g+w {} + # clean up permissions [12:53:55] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [12:56:36] !log wikidata-dev wikidata-new-wbterm updated core to d061c27f45 and Wikibase to 65656c9b38 [12:56:37] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [13:02:37] !log wikidata-dev wikidata-new-wbterm set tmpTermStoreMigrationStage and tmpPropertyTermsMigrationStage to MIGRATION_WRITE_NEW [13:02:39] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [13:24:33] !log wikidata-dev wikidata-new-wbterm update Wikibase to 79e8e62359 (I37b09764f5 PS5) [13:24:35] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [13:28:30] !log wikidata-dev wikidata-new-wbterm unset tmpTermStoreMigrationStage and tmpPropertyTermsMigrationStage [13:28:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [13:32:39] !log wikidata-dev wikidata-new-wbterm set up /etc/profile.d/umask.sh so that the default umask allows group-write, so different users can work with the /srv/mediawiki/html git repo without problems [13:32:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [14:08:42] hello. databases are broken on tools.wmflabs.org – tools either throw an error (/meta/stalktoy/) or have no data (/guc/). [14:08:55] is it a known outage? [14:09:26] "databases are broken" could you be more specific? [14:09:32] what is broken, which databases? [14:11:02] jynus: can you obtain any data from either tools.wmflabs.org/guc/ or tools.wmflabs.org/meta/stalktoy/ ? [14:11:20] guc is broken != databases [14:12:10] qq[IrcCity]: these are known issues: https://phabricator.wikimedia.org/T224930 [14:16:19] stalktoy is also broken, anyway. [14:16:32] I will check if there is any reports about that [14:16:43] if not, a new bug report would be needed indeed [14:17:54] I don't see any, do you want to report it, so you can give more details? [14:18:23] BTW, I can get data from stalktoy [14:19:03] but I wouldn't be surprised if it wasn't up to date for the latest edits [14:20:26] I just generated https://phab.wmfusercontent.org/file/data/fpgm3kqlry2nwwqrhvop/PHID-FILE-7pcaw74vinx4f5252g2n/Screenshot_20190604_161956.png [14:20:54] so it would be great if you could file a report with the problems you are seeing (I can help if necessary) [14:26:32] jynus: I narrowed the problem down to IP blocks. Thanks. [14:26:57] Accounts are not affected. [14:27:22] could you report it, I do thing the problem is real, but we should notify the tool maintainer [14:27:25] *think [14:27:31] yes, I will. [14:27:34] thanks [14:42:33] thanks jynus [14:54:58] for the stalktoy bug: now https://github.com/Pathoschild/Wikimedia-contrib/issues/126 [15:08:13] qq[IrcCity]: might wanna linkt to https://phabricator.wikimedia.org/T188327 [16:11:38] Some volunteer (with detailed knowledge) to update https://www.mediawiki.org/wiki/Manual:Revision_table (rev_user and rev_user_text does not exist any more, rev_actor ist new, maybe more) [16:58:45] Wurgl: good idea. I'll see if I can interest anomie in making some updates there :) [16:59:33] +1 [17:00:11] The big changes haven't completely happened in the production databases yet. We had to do them early in the Wiki Replicas so that the rolling changes in production over the coming week would not break out view layer over and over [17:00:32] bd808, Wurgl: rev_user and rev_user_text still exist in production though, and rev_actor doesn't exist yet in production. [17:00:58] anomie: is there a tracking task we could add an "update mw.o docs" sub-task to? [17:01:11] or does that already exist? [17:01:44] bd808: Not that I know of offhand. [17:02:00] anomie: Well, as a poor user, I can access replicas only and theses field are missing there. So my world ends there [17:02:13] Wurgl: we haven't shared this widely yet, but bstorm_ started a wikitech page yesterday about the changes that may be of some help -- https://wikitech.wikimedia.org/wiki/News/Actor_storage_changes_on_the_Wiki_Replicas [17:02:51] bstorm_: I think that page could go out on the mailing list whenever you are ready too :) [17:03:10] An update here would be fine too … https://commons.wikimedia.org/wiki/File:MediaWiki_1.28.0_database_schema.svg [17:20:21] bd808, anomie there is one [17:20:37] I commented on that some time ago [17:21:18] https://phabricator.wikimedia.org/T188183#5230261 [17:21:46] also on https://phabricator.wikimedia.org/T224862#5230246 [17:22:54] jynus: thanks! I think I'll start an explicit "update mediawiki.org docs" task and add those things in [17:23:03] ok to me [17:23:27] things will be confusing for folks for a little bit, but it will all come together! [17:23:46] bd808: sent the news page to cloud-announce on the same thread. I figure that's one of the best ways to find out what is missing from it. [17:24:04] bstorm_: from your email I take no more depooling for now on your side? [17:24:10] bstorm_: sounds perfect [17:24:44] Yup, I finished that yesterday, jynus. Wanted to make things consistent quickly [17:24:50] cool [17:24:56] I will continue the compression [17:25:03] Thanks! [17:25:04] we can stop relatively easilly [17:25:11] Also good to know [17:25:28] so ping at T222978 if you need it at any time [17:25:29] T222978: Compress and defragment tables on labsdb hosts - https://phabricator.wikimedia.org/T222978 [17:25:47] (you may want to unsub from that if that causes too much noise) [17:27:07] :) ok thanks [17:35:38] Wurgl, anomie, jynus: I created T225007. Edits welcome [17:35:40] T225007: Update operator/user manual description of database tables changed for refactored actor storage - https://phabricator.wikimedia.org/T225007 [17:36:11] thx [20:03:19] How do I get stop my queries from being killed after 14-37 minutes...? [20:03:42] Make them run quicker [20:04:05] bd808: Luckily I had to fix only 3 files, all some kind of no-brainer :-) so changes of _user to _actor was easy [20:06:18] Dispenser: are you hitting the *.analytics.db.svc.eqiad.wmflabs servers? They should have more tolerance for long queries [20:06:42] date; mysql -ch commonswiki.analytics.db.svc.eqiad.wmflabs commonswiki_p < wrong_ext_1.sql > output.tsv; date [20:07:08] Start: Tue Jun 4 12:28:45 UTC 2019; Killed: Tue Jun 4 12:42:58 UTC 2019 [20:10:40] *nod* some of that may have been caused by some maintenance work that has been continuing on the replicas