[00:57:34] andrewbogott: It seems mounts aren't mounting in the new instance integration-slave1010 [00:57:37] created > 1h ago [00:57:41] puppet has run a few times [00:57:48] (unforced, just from natural schedule) [00:57:57] Feb 20 00:55:43 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Notify[hostname: integration-slave1010]/message) defined 'message' as 'hostname: integration-slave1010' [00:57:57] Feb 20 00:55:43 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Mount[/home]/ensure) ensure changed 'unmounted' to 'mounted' [00:57:58] Feb 20 00:55:43 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Mount[/home]) Could not evaluate: Execution of '/bin/mount /home' returned 32: mount.nfs: mounting labstore.svc.eqiad.wmnet:/project/integration/home failed, reason given by server: No such file or directory [00:58:24] Feb 20 00:55:43 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Notify[instanceproject: integration]/message) defined 'message' as 'instanceproject: integration' [00:58:24] Feb 20 00:55:47 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Mount[/data/project]/ensure) ensure changed 'unmounted' to 'mounted' [00:58:24] Feb 20 00:55:47 integration-slave1010 puppet-agent[28430]: (/Stage[main]/Role::Labs::Instance/Mount[/data/project]) Could not evaluate: Execution of '/bin/mount /data/project' returned 32: mount.nfs: mounting labstore.svc.eqiad.wmnet:/project/integration/project failed, reason given by server: No such file or directory [00:59:33] Krinkle: there’s a race condition with new instances. Reboot it? [01:00:01] andrewbogott: OK. [01:00:09] andrewbogott: Typically how long for a reboot before it's safe to ssh into it? [01:00:25] a minute or so [01:00:56] andrewbogott: is there a task about this race condition? [01:01:24] Krinkle: I don’t know. I added an explicit first-boot delay in the Jessie image which seems to have mostly fixed it for debian. [01:01:24] Mounted :) [01:01:31] Thx [01:25:23] 3Continuous-Integration, Wikimedia-Labs-Infrastructure: Fix "Error: /Stage[main]/Contint::Packages/File[/etc/php5/conf.d/apc.ini]/ensure: change from absent to file failed" - https://phabricator.wikimedia.org/T90039#1051961 (10Krinkle) 3NEW [03:57:36] 3Tool-Labs: meta_p.wiki's column size is 1 for all wikis - https://phabricator.wikimedia.org/T90084#1052259 (10scfc) 3NEW a:3coren [04:00:44] 3Tool-Labs: Missing or wrong information in meta_p.wiki table - https://phabricator.wikimedia.org/T56962#1052270 (10scfc) 5Open>3Resolved >>! In T56962#1051546, @jayvdb wrote: > Is T69476 part of the scope of this task? No, that should be handled there. Regarding the `size` column, looking at `maintain-rep... [05:45:36] PROBLEM - Free space - all mounts on tools-webproxy is CRITICAL: CRITICAL: tools.tools-webproxy.diskspace._var.byte_percentfree.value (<25.00%) [06:20:39] RECOVERY - Free space - all mounts on tools-webproxy is OK: OK: All targets OK [08:19:38] andrewbogott_afk: sure [09:28:27] 3Labs, ops-eqiad, operations: virt1002 broken disk? - https://phabricator.wikimedia.org/T88923#1052512 (10faidon) @Jgreen, it has a MegaRAID SAS controller, so you need `megacli`, not `mpt-status`. [10:15:12] is something wrong ? Tools like Reasonator no longer work reliably [10:17:45] 3Labs, ops-eqiad, operations: virt1002 broken disk? - https://phabricator.wikimedia.org/T88923#1052604 (10fgiunchedi) @jgreen I have come across this before, see T84981 (basically mpt-status doesn't work on the cisco but lsiutil does) [11:04:09] PROBLEM - Host tools-webproxy-jessie is DOWN: CRITICAL - Host Unreachable (10.68.17.147) [11:05:15] 3Wikimedia-Labs-Infrastructure: Weird state of /data/project for dumps (semi-missing files) - https://phabricator.wikimedia.org/T87224#1052815 (10Hydriz) This is probably something that appears when the Labs NFS gets a hiccup. Restarting the server should resolve the problem. Perhaps this is something that can... [11:36:59] PROBLEM - Puppet staleness on tools-exec-15 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [43200.0] [13:26:37] PROBLEM - Free space - all mounts on tools-webproxy is CRITICAL: CRITICAL: tools.tools-webproxy.diskspace._var.byte_percentfree.value (<25.00%) [13:43:38] 3Tool-Labs: Migrate tools to trusty - https://phabricator.wikimedia.org/T88228#1053141 (10JanZerebecki) [13:45:43] 3Tool-Labs: Make HHVM based webservices available on toollabs - https://phabricator.wikimedia.org/T78783#1053143 (10JanZerebecki) [14:03:11] 3Continuous-Integration, Wikimedia-Labs-Infrastructure: Fix "Error: /Stage[main]/Contint::Packages/File[/etc/php5/conf.d/apc.ini]/ensure: change from absent to file failed" - https://phabricator.wikimedia.org/T90039#1053166 (10Krinkle) [14:04:27] 3Continuous-Integration, Wikimedia-Labs-Infrastructure: Fix "Error: /Stage[main]/Contint::Packages/File[/etc/php5/conf.d/apc.ini]/ensure: change from absent to file failed" - https://phabricator.wikimedia.org/T90039#1051961 (10Krinkle) [14:11:38] RECOVERY - Free space - all mounts on tools-webproxy is OK: OK: All targets OK [14:32:18] 3Pywikibot-compat-to-core, Tool-Labs, pywikibot-core: Install all pywikibot python dependencies on tool labs - https://phabricator.wikimedia.org/T86015#1053266 (10JanZerebecki) [14:36:29] 3Wikimedia-Hackathon-2015, Labs: Labs web proxy should be load-balanced and tolerate the failure of virt host - https://phabricator.wikimedia.org/T89995#1053273 (10Qgil) p:5Triage>3Low [14:47:35] PROBLEM - Free space - all mounts on tools-webproxy is CRITICAL: CRITICAL: tools.tools-webproxy.diskspace._var.byte_percentfree.value (<12.50%) [14:48:00] GerardM-: do you still have problems with reasonator? [15:02:40] RECOVERY - Free space - all mounts on tools-webproxy is OK: OK: All targets OK [15:08:46] jzerebecki: Reasonator seems stable at the moment [15:14:17] 3Labs, Wikimedia-Labs-Infrastructure: Internal DNS look-ups fail every once in a while - https://phabricator.wikimedia.org/T72076#1053410 (10hashar) I guess we want a task to request a second DNS resolver in the wmflabs :] [15:19:01] jzerebecki: the toolscript is now broken [15:19:12] and as it is a chain I am stuck [15:48:11] YuviPanda, hi, i just did a git pull on lab's vagrant, and now labs-vagrant list-roles [15:48:11] fails. I tried doing apt-get update & ugrade, but didn't help. I get this message: [15:48:32] /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mediawiki-vagrant/settings (LoadError) [15:51:12] yurik: bah. I know what broke that. File a bug please and assign to me [15:51:31] Dan did some refactoring in the vagrant plugin and moved the cheese [15:52:32] yurik: if you want a quick hack fix, revert c975cab872f3f8ef37a4cc5f278287af0b98c5dd locally [15:53:11] 3Labs, ops-eqiad, operations: virt1002 broken disk? - https://phabricator.wikimedia.org/T88923#1053653 (10coren) 5Open>3Resolved New disk is in place, and resyncing. [15:53:45] bd808, thx, created. Will the labs instance break if i do a apt-get upgrade? [15:54:34] It shouldn't but be sure to force a puppet run followed by labs-vagrant provision after [15:55:09] sudo puppet agent --test --verbose to force a puppet run with the normal labs puppet rules [15:55:53] bd808, thx! Btw, revert is not clean, so might want to wait for the patch ( [15:56:20] *nod* I should be able to get something working this morning (no meetings!) [16:03:21] wow, somehow my graph instance lost its static ip. Is it broken again? [16:06:13] this is not good at all - we gave that ip to partners [16:06:33] could someone check why zero.wmflabs.org has lost its static ip? [16:07:05] yurik: Define "lost"? [16:07:12] also, i'm unable to view dns [16:07:25] Coren, well, it was assigned a static ip, now it resolves to a different ip [16:07:42] yurik: ... what? What project is this? [16:07:44] and nothing shows in the manage address [16:07:48] mediawiki-api [16:08:37] graph3 at 208.80.155.201? [16:08:45] i think so [16:08:54] yes [16:09:29] Coren, correction - it seems that the mapping is still there [16:09:32] All of this works for me, from inside and outside or network both. [16:09:41] it is just not showing up in the management [16:09:42] interface [16:10:02] yurik: Your keystone token is probably expired - log off an on again wikitech? [16:10:10] sigh [16:10:34] Coren, thanks ( [16:10:51] i keep forgetting that trick ) [16:13:13] could someone restart https://tools.wmflabs.org/quick-intersection/ ? [16:15:08] jzerebecki: The tool, she runs! [16:15:14] bd808, error: insufficient permission for adding an object to repository database .git/objects [16:15:14] when doing git-update - do you know anything about it? there is no user vagrant in /etc/passwd [16:15:36] Coren: thx [16:15:55] yurik: check who owns your /vagrant/.git directory [16:15:57] GerardM-: try again please ^^ [16:16:17] yurik: oh git-update; check /vagrant/mediawiki/.git [16:17:00] bd808, drwxrwsr-x 8 vagrant wikidev 4096 Feb 20 16:15 .git [16:17:09] git pull works by itself btw [16:17:16] but not from labs-vagrant [16:17:58] hmmm... [16:19:00] yurik: what does ls -ld /vagrant/mediawiki/.git/objects tell you? [16:19:30] bd808, drwxrwsr-x 7 vagrant wikidev 4096 Sep 3 01:53 /vagrant/mediawiki/.git/objects [16:20:04] that looks right oo [16:20:06] *too [16:21:06] jzerebecki: it is fine now :) [16:21:08] thanks [16:21:13] what was it ? [16:21:17] bd808, git-update succeedes on core, but fails on exts: [16:21:44] # ls -ld /vagrant/mediawiki/extensions/JsonConfig/.git/objects [16:21:44] drwxrwsr-x 44 vagrant wikidev 4096 Sep 20 19:19 /vagrant/mediawiki/extensions/JsonConfig/.git/objects [16:22:19] ah. so perms are likely messed up in one of your extension checkouts. Maybe something you've been hacking on locally? [16:22:23] GerardM-: the webserver for https://tools.wmflabs.org/quick-intersection/ was not running anymore [16:22:36] bd808, not really - it is messed up differently in all of them [16:22:43] and i wasn't hacking on all [16:23:23] # ls -ld /vagrant/mediawiki/extensions/SyntaxHighlight_GeSHi/.git/FETCH_HEAD [16:23:23] -rw-rw-r-- 1 root wikidev 6534 Sep 20 19:20 /vagrant/mediawiki/extensions/SyntaxHighlight_GeSHi/.git/FETCH_HEAD [16:23:34] this one is root for some reason [16:23:46] weird [16:24:53] it would be nice if something knew which services needed to be running and start them when necessary... [16:25:21] yurik: try cherry picking https://gerrit.wikimedia.org/r/#/c/191895/ for the labs-vagrant ruby load error [16:29:13] yurik: labs-vagrant git-update runs as whatever user you invoke the command as (no hidden sudo) so either fix your git clone perms or run with sudo as root [16:33:31] bd808, cherry pciked, worked [16:33:35] thanks! [16:34:10] yurik: +1 the patch and I'll self-merge [16:34:10] bd808, i am running as sudo -s -- git pull works by itself, but not as labs-vagrant git-update [16:34:49] `sudo -s -- git pull ` == root; `labs-vagrant git-update` == you [16:35:14] bd808, +2ed [16:35:20] excellent [16:36:05] bd808, do you have another moment - trying to get https://gerrit.wikimedia.org/r/#/c/191887/ to work on labs [16:36:15] npm fails ( [16:36:29] lots of fire and smoke when using node [16:37:33] you'll need to do fancier things if you want to exec npm in a project [16:37:50] but I still don't know why you would because nothing like that will ever make it to prod [16:39:00] yurik: you'll really need things like https://github.com/wikimedia/mediawiki-vagrant/blob/master/puppet/modules/php/manifests/composer.pp and https://github.com/wikimedia/mediawiki-vagrant/blob/master/puppet/modules/php/manifests/composer/install.pp [16:39:53] bd808, well, i need to install vega, which compiles some native code - any thoughts? When i do npm install vega, it does the compilation [16:41:03] maybe something like https://github.com/puppetlabs/puppetlabs-nodejs/blob/master/lib/puppet/provider/package/npm.rb [16:41:22] puppet isn't batteries included for managing nodejs packages [16:41:37] so you need to add that somehow [16:42:00] or find the package you need via apt somewhere [16:44:12] yurik: how do you envision getting vega in prod? Or its this not going to eventually run on the WMF cluster? [16:44:38] bd808, no idea really - it seems mathoid has built a debian package [16:44:45] and they needed similar stuff [16:45:18] no matter how we look at it, we will need to resolve NPM issue if we are to have any node.js services [16:45:50] well we have several nodejs services and no npm magic yet [16:46:20] so the way I look at it do what the others have done [16:46:24] take a look at mathoid - they had to go through tons of sh*t to get around it, it seems [16:46:48] i am totally ok with that, just not sure what that is ) [16:47:32] https://github.com/wikimedia/mediawiki-vagrant/blob/master/puppet/modules/role/manifests/mathoid.pp [16:47:37] looks pretty simple to me [16:47:57] https://github.com/wikimedia/mediawiki-vagrant/tree/master/puppet/modules/mathoid/manifests [16:48:28] git::clone{ 'mediawiki/services/mathoid' ... and it's basically done [16:49:42] I think maybe you should be asking physkerwelt, gwicke and others who have built nodejs services for prod what the steps are [16:50:21] yeah, i think i need to work closer with them [16:50:24] bd808, https://github.com/wikimedia/mathoid [16:50:47] tons of debian package stuff ( [16:52:17] yurik: we are working on automating the packaging [16:52:49] gwicke, awesome! :) Any suggestions on how to deploy graphoid though? It seems to be complete ) [16:52:51] https://github.com/wikimedia/service-runner will establish a standard way to configure & start services [16:53:02] which in turn lets us use the same sauce for each package [16:53:05] i mean - the service is working ) [16:54:23] so far the ugly way to deploy services is using a deploy repo pulling in the actual source as a submodule [16:54:35] and then use trebuchet to push that out [16:54:44] followed by ssh-based restarts [16:55:23] you are responsible for running npm install manually, removing nested gitignore files, checking in node_modules & keeping it up to date [16:56:46] gwicke, there is a problem :(( installing npm module "vega" causes binary compilation [16:56:56] in one of its dependencies [16:57:02] that's normal [16:57:02] either d3 or something [16:57:16] so you better locally run the same distro as we use in prod.. [16:57:41] but from what i saw in mathoid , you have checked in all the node_modules into git [16:57:51] do you want me to check in binaries into git? [16:57:59] yes, it's the only way for now [16:58:04] bleh ) [16:58:13] until we move to artifact-based deploys [16:58:16] and automate the build [16:58:37] PROBLEM - Free space - all mounts on tools-webproxy is CRITICAL: CRITICAL: tools.tools-webproxy.diskspace._var.byte_percentfree.value (<12.50%) [17:01:40] bd808, do you know if the distro we use for vagrant the same as in prod? [17:02:32] it is, yes [17:02:58] modulo that prod is starting to switch things to Debian Jessie slowly and we haven't made that jump yet [17:03:13] but Ubuntu 14.04 is the distro for the prod MW servers [17:08:35] RECOVERY - Free space - all mounts on tools-webproxy is OK: OK: All targets OK [17:10:36] gwicke, do i need to clone the /debian dir in mathoid ? [17:14:11] is vagrant on jessie yet? [17:14:25] not yet [17:14:30] ah, k [17:14:38] I would start anything new on jessie really [17:14:46] to avoid upstart-ism creeping in etc [17:15:10] we had so much disruption with the precise to trusty switch it doesn't seem worth it yet [17:15:15] yurik: you shouldn't need to manually create a deb [17:15:28] We could try to start a branch I suppose. [17:15:50] yurik: but I'd encourage you to look at https://github.com/wikimedia/service-runner [17:16:10] it sets up standard clustering, logging, metrics & yaml config loading [17:16:10] But I don't know if there is a plan to move the MW servers to jessie in the near term. That would be the timeline we'd be most likely to follow for mw-vagrant [17:16:34] the restbase deploy is on jessie [17:16:54] I would definitely recommend to use it for anything new [17:16:58] gwicke, i am totally up for it, but is it ready to be used? [17:17:28] the sca cluster is still on trusty though [17:17:52] yurik: it's available for new boxes [17:18:00] if we had containers it would be available anywhere ;) [17:18:16] it's available in labs [17:18:30] is there a doc on how to get started with it? [17:18:48] there's basically no difference for most purposes [17:19:05] the only real difference is that trusty still uses upstart, while jessie is already using systemd [17:19:18] both support init scripts, which is what we are using with restbase [17:19:54] both are on node 0.10 [17:20:33] yurik: re the service-runner: we are using it in restbase already [17:20:59] there's still some fine-tuning to be done around the edges, but that shouldn't affect you [17:21:02] basically i'm looking for a "best practices" guide/tutorial: e.g. copy this repo, add your code to file blah.js, add configurations. To run on vagrant do this, to deploy in production do that. [17:21:22] i will look at restbase more [17:21:47] yurik: we just created a template at https://github.com/wikimedia/service-template-node [17:22:08] it's still very hot, but hopefully already useful [17:22:14] lol, 23 seconds is good ) [17:22:24] i like freshly baked code [17:24:04] we are looking into https://github.com/krakenjs/swaggerize-express as well [17:24:30] will be easy to hook up later though [17:25:01] btw, restbase just went public: http://rest.wikimedia.org/en.wikipedia.org/v1/?doc [17:29:58] 3Labs, Wikimedia-Labs-Infrastructure: Set up second DNS server for Labs instances - https://phabricator.wikimedia.org/T90234#1054193 (10scfc) 3NEW [17:30:21] gwicke, congrats!!!!!!!!!!!!!!!!! [17:30:38] 3Labs, Wikimedia-Labs-Infrastructure: Set up second DNS server for Labs instances - https://phabricator.wikimedia.org/T90234#1054211 (10scfc) [17:30:39] huge step!!! [17:30:40] 3Labs, Wikimedia-Labs-Infrastructure: Internal DNS look-ups fail every once in a while - https://phabricator.wikimedia.org/T72076#720916 (10scfc) [17:31:04] yurik: yup, finally ;) [17:31:19] gwicke, i just ran npm instal - is this right? https://gerrit.wikimedia.org/r/#/c/191909/ [17:31:44] 3Labs, Wikimedia-Labs-Infrastructure: Internal DNS look-ups fail every once in a while - https://phabricator.wikimedia.org/T72076#720916 (10scfc) Done with T90234, here as a blocked task on the assumption that this task is about fixing the networking bottleneck. [17:32:33] yurik: looks okay at first sight [17:32:44] sigh, ok, commiting, will see ) [17:32:51] one gotcha about checking in node_modules is that nested .gitignore files can mess with you [17:33:13] so I always do a find node_modules -name '.gitignore' | xargs rm [17:33:32] haven't found a better way to do this yet [17:33:46] for some reason i didn't see any [17:34:10] yurik: oh, just noticed that this is your actual service repo [17:34:23] that's ugly [17:34:28] now you are telling me ) [17:35:00] we normally work around the worst of the uglyness by using a second deploy repo, which has the actual code as a submodule [17:35:15] normally in src [17:35:25] example: https://github.com/wikimedia/mediawiki-services-parsoid-deploy [17:35:57] it's all an ugly hack, but beats messing up your actual service repo with node_modules [17:36:20] downside is that you get all the disadvantages of submodules in the trade [17:37:25] thanks, i will request another repo for that [17:37:29] yurik: btw, you might want to hop over to #wikimedia-services [17:37:49] although I see that mobrovac is here as well [17:52:00] 3Wikimedia-Labs-Infrastructure: Labs: both Icinga and Ganglia not accessible: 502 Bad Gateway - https://phabricator.wikimedia.org/T85318#1054268 (10scfc) Icinga is now gone: ``` [tim@passepartout ~]$ host icinga.wmflabs.org Host icinga.wmflabs.org not found: 3(NXDOMAIN) [tim@passepartout ~]$ ``` but Ganglia st... [17:52:16] 3Wikimedia-Labs-Infrastructure: Labs: both Icinga and Ganglia not accessible: 502 Bad Gateway - https://phabricator.wikimedia.org/T85318#1054272 (10scfc) 5declined>3Open a:5yuvipanda>3None [18:00:01] 3Wikimedia-Labs-Infrastructure: Labs: both Icinga and Ganglia not accessible: 502 Bad Gateway - https://phabricator.wikimedia.org/T85318#1054292 (10Se4598) Another idea would be to setup a simple redirect/landing page pointing to https://tools.wmflabs.org/nagf/ and/or https://tools.wmflabs.org/nagf/ [18:07:43] Coren, sorry to bug you again - i enabled a port forwarding, but its not working -- http://graph.wmflabs.org:11042/ - i added 11042 to the web sec group [18:08:24] i ran sudo puppet agent --test --verbose on the host too [18:08:30] yurik: You're not bugging - I'm here to help. :-) [18:08:39] )) [18:11:29] Wait, why aren't you using 'zero.wmflabs.org'? [18:13:07] yurik: graph.wmflabs.org is not pointing at your project, zero is. :-) [18:13:25] Coren, they both are, aren't they? [18:13:40] I only see zero [18:13:55] check https://wikitech.wikimedia.org/wiki/Special:NovaAddress [18:14:25] they both resolve to the same static ip [18:15:22] zero.wmflabs.org has address 208.80.155.201 [18:15:22] graph.wmflabs.org has address 208.80.155.156 [18:18:36] Coren, hmm.. weird, i guess one of them is going via a proxy. For some reason i can't manage the proxy -- this page shows no entries - https://wikitech.wikimedia.org/wiki/Special:NovaProxy [18:18:53] but still, neither one works [18:18:56] for port forwarding [18:20:28] The proxy does http and https only - that's normal. [18:20:59] zero works, the connection goes all the way to graph3 which is the holder of the IP - but there's nothing listening on that port in that instance. Is your daemon down? [18:27:49] Coren, might have been confused with the instances, checking. Is it normal that i see no entries in manage web proxies for mediawiki-api project? [18:28:18] Well, unless you specifically added one there then it's normal. The web proxy is elective. [18:33:31] Ah, but I see it's supposed to point to graph3; which means it should show. Odd. [18:35:46] exactly )) [18:36:44] Coren, works! http://zero.wmflabs.org:11042/ [18:37:07] seems like the problem is that graph and zero do not point to the same instance [18:37:10] even though they sohuld be [18:37:35] No, it does, but only for http and https [18:37:40] No other port need apply. [18:37:57] zero is a "real" public IP which you can do whatever you want with [18:39:48] but how would i make other ports point, via webproxy? We are begining to implement lots of services, and most likely they will sit on other ports [18:40:43] yurik: You cannot. webproxy is very specifically a /web/ proxy. You'll have to do it in-project. [18:41:35] how do you mean "in-project"? Each project will get a static ip? [18:42:18] No, I mean - zero.wmflabs.org points at your graph3 instance atm; any port you want to open /there/ will work fine. [18:43:47] (03CR) 10Merlijn van Deen: [C: 032] Match all projects, even if a channel is already used [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190933 (https://phabricator.wikimedia.org/T89644) (owner: 10Merlijn van Deen) [18:43:50] Coren, yes, but zero was a special case because we wanted to give a static ip to test to one of our partners - this has nothing to do with the service development that many groups are engaging in [18:44:16] (03Merged) 10jenkins-bot: Match all projects, even if a channel is already used [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190933 (https://phabricator.wikimedia.org/T89644) (owner: 10Merlijn van Deen) [18:44:19] (03CR) 10Merlijn van Deen: [C: 032] Improve wikibugs color scheme [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190858 (https://phabricator.wikimedia.org/T89632) (owner: 10Merlijn van Deen) [18:44:35] (03Merged) 10jenkins-bot: Improve wikibugs color scheme [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190858 (https://phabricator.wikimedia.org/T89632) (owner: 10Merlijn van Deen) [18:44:45] (03CR) 10Merlijn van Deen: [C: 032] Always show four tags, most relevant first [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190936 (https://phabricator.wikimedia.org/T89634) (owner: 10Merlijn van Deen) [18:44:57] That's my point; if you want/need to listen on anything but http over port 80, you have to assign a static IP and use that. The web proxy is exactly just that, by design, to cover the other 99% of use case for ingress to labs. :-) [18:45:11] (03Merged) 10jenkins-bot: Always show four tags, most relevant first [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190936 (https://phabricator.wikimedia.org/T89634) (owner: 10Merlijn van Deen) [18:46:25] !log tools.wikibugs valhallasw: Deployed 4cf33271a75d3655addac95cc16413ab1adc6488 Merge "Always show four tags, most relevant first" wb2-irc [18:46:28] Logged the message, Master [18:47:01] dum dum DUUUUM [18:49:50] 10Wikibugs: wikibugs test bug - https://phabricator.wikimedia.org/T1152#19999 (10valhallasw) [18:54:43] has anything changed on tool labs today wrt. to Tomcat? my tomcat based app suddenly doesn't work properly anymore, caused by memory problems it seems. [19:10:07] anyone knows how to launch mwscript shell on vagrant mediawiki in labs? [19:12:14] bd808|LUNCH, i know you do ) ^ [19:19:23] Hey guys, one easy question regarding mediawiki database. [19:19:30] I am just trying to compute inlinks for each article [19:19:43] I would like to know if this is a good query [19:19:55] SELECT pl_title, COUNT(*) FROM pagelinks INNER JOIN page ON pl_title=page_title WHERE pl_namespace=0 AND pl_from_namespace=0 AND page_namespace=0 AND page_is_redirect=0 GROUP by pl_title [19:20:06] it seems very slow to me and I don't know if there is any better [19:20:56] I tried also without the Inner join with page [19:59:00] (03PS1) 10Legoktm: More fundraising repos to #wikimedia-fundraising [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/191939 [19:59:13] (03PS2) 10Legoktm: More fundraising projects to #wikimedia-fundraising [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/191939 [19:59:18] (03CR) 10Legoktm: [C: 032] More fundraising projects to #wikimedia-fundraising [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/191939 (owner: 10Legoktm) [20:00:06] (03Merged) 10jenkins-bot: More fundraising projects to #wikimedia-fundraising [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/191939 (owner: 10Legoktm) [20:04:01] !log tools.wikibugs Updated channels.yaml to: 26b8b9f5f812b092b02d33b3b29cf448dafb663a More fundraising projects to #wikimedia-fundraising [20:04:03] Logged the message, Master [20:04:34] 10Wikibugs: Some projects get lost - https://phabricator.wikimedia.org/T90267#1055060 (10valhallasw) 3NEW [20:05:57] 10Wikibugs, 5Patch-For-Review: Report 'and X more' in a different way - https://phabricator.wikimedia.org/T89634#1055078 (10valhallasw) 5Open>3Resolved a:3valhallasw [20:06:08] 10Wikibugs, 5Patch-For-Review: Problems with the new color scheme - https://phabricator.wikimedia.org/T89632#1055080 (10valhallasw) 5Open>3Resolved a:3valhallasw [20:06:17] 10Wikibugs, 5Patch-For-Review: Color floods into the main text and url in irssi - https://phabricator.wikimedia.org/T89633#1055082 (10valhallasw) 5Open>3Resolved a:3valhallasw [20:06:26] 10Wikibugs, 5Patch-For-Review: make sure to match all projects against all regexes - https://phabricator.wikimedia.org/T89644#1055084 (10valhallasw) 5Open>3Resolved a:3valhallasw [20:25:14] Coren, is it possible to loopback from labs? e.g. access http://zero.wmflabs.org/w/api.php from the server? [20:25:35] Not with the external IP, no. You'll have to use the internal one. [20:25:52] boo [20:53:31] 10Wikibugs: Roses are red, but the "Sprint" projects aren't - https://phabricator.wikimedia.org/T90276#1055240 (10matmarex) 3NEW [20:54:23] ^ bikeshedding, literally [20:54:42] color discussions [22:01:14] 10Wikimedia-Labs-Infrastructure: Switch to using nova internal DNS - https://phabricator.wikimedia.org/T90289#1055468 (10Krenair) [22:01:28] 10MediaWiki-extensions-OpenStackManager, 10Wikimedia-Labs-Infrastructure: Switch to using nova internal DNS - https://phabricator.wikimedia.org/T90289#1055461 (10Krenair) [22:32:30] 10Wikibugs: Roses are red, but the "Sprint" projects aren't - https://phabricator.wikimedia.org/T90276#1055543 (10valhallasw) 5Open>3declined a:3valhallasw Well, it's two things. First, the chosen colors are a bit redder (i.e. orange instead of yellow) because yellow is invisible on a white background. Se... [23:45:32] (03CR) 10Krinkle: "Can we not add underlines please?" [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190858 (https://phabricator.wikimedia.org/T89632) (owner: 10Merlijn van Deen) [23:52:51] (03CR) 10Krinkle: "Also from UX I'd strongly recommend not to use red under any circumstances as it distracts greatly." [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/190858 (https://phabricator.wikimedia.org/T89632) (owner: 10Merlijn van Deen)