[00:04:50] 10Scap, 06WMF-Legal, 07Documentation, 07Software-Licensing: Scap is lacking a license - https://phabricator.wikimedia.org/T94239#3059840 (10mmodell) [01:11:39] PROBLEM - Check for valid instance states on labnodepool1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [01:19:56] 10Scap, 06WMF-Legal, 07Documentation, 07Software-Licensing: Scap is lacking a license - https://phabricator.wikimedia.org/T94239#3059981 (10mmodell) 05Open>03Resolved [01:43:07] 10Continuous-Integration-Infrastructure, 07Puppet: Need a better way of testing puppet patches for contint/integration stuff - https://phabricator.wikimedia.org/T126370#3060034 (10scfc) >>! In T126370#2046565, @hashar wrote: > @scfc great teaser. I would like to know more about environments. > > Is all that lo... [02:19:29] 10Scap, 06WMF-Legal, 07Documentation, 07Software-Licensing: Scap is lacking a license - https://phabricator.wikimedia.org/T94239#3060082 (10Ricordisamoa) [02:35:39] PROBLEM - Check for valid instance states on labnodepool1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [02:38:22] 10Scap: Make scap plugins generally useful - https://phabricator.wikimedia.org/T151470#2818345 (10demon) I don't remember what "useful" meant. [02:38:45] twentyafterfour: Heh ^ [02:42:47] 10Scap: Make scap plugins generally useful - https://phabricator.wikimedia.org/T151470#3060145 (10mmodell) I think it meant more docs and a set of APIs which are 'blessed' as stable and usable. The main thing I had in mind here was to clearly differentiate the stable parts from the //internal// APIs which shoul... [02:43:01] RainbowSprinkles: ....^ I think I remember [02:43:43] * RainbowSprinkles nods [02:43:49] That seems like a plausible explanation [02:47:31] 10Scap, 07Documentation: Define a stable API for scap plugins - https://phabricator.wikimedia.org/T151470#3060147 (10mmodell) [02:47:37] re-titled [02:49:23] So far the only api we're extending in plugins is cli.Application [03:25:59] 10Scap, 06WMF-Legal, 07Documentation, 07Software-Licensing: Scap is lacking a license - https://phabricator.wikimedia.org/T94239#3060171 (10Legoktm) @mmodell and co.: thank you for pushing this forward! [03:39:05] (03PS1) 10Legoktm: tox: Add flake8-bin3 env to lint scripts that don't end in .py [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340279 [03:39:08] (03PS1) 10Legoktm: Refactor git-changed-in-head to use a class [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340280 [03:39:59] (03CR) 10jerkins-bot: [V: 04-1] Refactor git-changed-in-head to use a class [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340280 (owner: 10Legoktm) [03:41:11] (03PS2) 10Legoktm: Refactor git-changed-in-head to use a class [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340280 [03:44:50] (03CR) 10Legoktm: [C: 032] "I've implemented your suggestions in follow-up patches. Gonna give this a try!" (032 comments) [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340181 (owner: 10Legoktm) [03:44:56] (03CR) 10Legoktm: [C: 032] Don't lint composer/autoload_static.php [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340182 (https://phabricator.wikimedia.org/T136021) (owner: 10Legoktm) [03:45:01] (03CR) 10Legoktm: [C: 032] tox: Add flake8-bin3 env to lint scripts that don't end in .py [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340279 (owner: 10Legoktm) [03:45:42] (03Merged) 10jenkins-bot: Port git-changed-in-head to Python [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340181 (owner: 10Legoktm) [03:45:51] (03Merged) 10jenkins-bot: Don't lint composer/autoload_static.php [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340182 (https://phabricator.wikimedia.org/T136021) (owner: 10Legoktm) [03:45:54] (03Merged) 10jenkins-bot: tox: Add flake8-bin3 env to lint scripts that don't end in .py [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340279 (owner: 10Legoktm) [03:57:10] so uh [03:57:17] git-changed-in-head has been broken for quite a while now [03:57:40] we do shallow clones so every file was changed in HEAD [03:58:09] so the script basically does `find .` [04:00:15] 10Continuous-Integration-Config, 10Continuous-Integration-Infrastructure, 13Patch-For-Review: Update git-change-in-head script to be able to allow us to ignore files - https://phabricator.wikimedia.org/T136021#3060187 (10Legoktm) 05Open>03Resolved a:03Legoktm [04:01:16] 10Continuous-Integration-Infrastructure, 07Composer, 13Patch-For-Review: Upgrade integration/composer to 1.3.2 stable - https://phabricator.wikimedia.org/T125343#3060193 (10Legoktm) [04:05:29] PROBLEM - puppet last run on contint2001 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [04:06:06] oh [04:06:12] I guess it's useful when we don't do shallow clone [04:33:29] RECOVERY - puppet last run on contint2001 is OK: OK: Puppet is currently enabled, last run 27 seconds ago with 0 failures [04:42:31] 10MediaWiki-Releasing, 10MediaWiki-Containers, 06Services, 15User-mobrovac: Ready-to-use Docker package for MediaWiki - https://phabricator.wikimedia.org/T92826#3060213 (10Dan.mulholland) Thanks @Ryan.lewkowicz this looks like a great piece of work. I have separately been creating quite a complex docker sy... [06:42:53] PROBLEM - Puppet run on deployment-mathoid is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [06:43:22] PROBLEM - Puppet run on deployment-mediawiki06 is CRITICAL: CRITICAL: 50.00% of data above the critical threshold [0.0] [06:43:50] PROBLEM - Puppet run on deployment-cache-text04 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:44:37] PROBLEM - Puppet run on deployment-parsoid09 is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [06:44:41] PROBLEM - Puppet run on deployment-redis02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [06:45:25] PROBLEM - Puppet run on deployment-conf03 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:47:53] PROBLEM - Puppet run on deployment-fluorine02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [06:48:13] PROBLEM - Puppet run on deployment-zotero01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:48:23] PROBLEM - Puppet run on deployment-kafka04 is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [06:48:26] PROBLEM - Puppet run on deployment-mcs01 is CRITICAL: CRITICAL: 40.00% of data above the critical threshold [0.0] [06:48:29] PROBLEM - Puppet run on deployment-logstash2 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [06:48:32] PROBLEM - Puppet run on deployment-pdfrender02 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:48:58] PROBLEM - Puppet run on deployment-phab01 is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [06:49:06] PROBLEM - Puppet run on deployment-phab02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [06:49:24] PROBLEM - Puppet run on deployment-changeprop is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:49:28] PROBLEM - Puppet run on deployment-zookeeper01 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [06:49:30] PROBLEM - Puppet run on deployment-mediawiki05 is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [06:49:30] PROBLEM - Puppet run on deployment-urldownloader is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [06:49:48] PROBLEM - Puppet run on deployment-sca03 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:50:36] PROBLEM - Puppet run on deployment-elastic06 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [06:51:08] PROBLEM - Puppet run on deployment-jobrunner02 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [06:51:58] PROBLEM - Puppet run on deployment-prometheus01 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:52:04] PROBLEM - Puppet run on deployment-apertium02 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [06:52:05] PROBLEM - Puppet run on deployment-copper is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [06:52:11] PROBLEM - Puppet run on deployment-salt02 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [06:52:45] PROBLEM - Puppet run on deployment-puppetdb01 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:52:59] PROBLEM - Puppet run on deployment-mira is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [06:53:05] PROBLEM - Puppet run on deployment-aqs01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:53:06] PROBLEM - Puppet run on deployment-kafka05 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:53:20] PROBLEM - Puppet run on deployment-eventlogging03 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:53:26] PROBLEM - Puppet run on deployment-puppetmaster02 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:53:48] PROBLEM - Puppet run on deployment-mx is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [06:54:30] PROBLEM - Puppet run on deployment-stream is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [06:56:09] PROBLEM - Puppet run on deployment-ores-redis is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [06:57:16] PROBLEM - Puppet run on deployment-sca01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:57:19] PROBLEM - Puppet run on deployment-trending01 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [06:57:27] PROBLEM - Puppet run on deployment-tin is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [06:57:36] PROBLEM - Puppet run on deployment-pdf01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [06:58:10] PROBLEM - Puppet run on deployment-ircd is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [06:58:14] PROBLEM - Puppet run on deployment-mediawiki04 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [06:58:30] PROBLEM - Puppet run on deployment-sca02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [07:01:11] PROBLEM - Puppet run on deployment-restbase02 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [07:01:15] PROBLEM - Puppet run on deployment-kafka03 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [07:01:15] PROBLEM - Puppet run on deployment-memc04 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [07:02:17] PROBLEM - Puppet run on deployment-sentry01 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [07:02:31] PROBLEM - Puppet run on deployment-poolcounter04 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [07:03:06] PROBLEM - Puppet run on deployment-ms-be01 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [07:03:10] PROBLEM - Puppet run on deployment-imagescaler01 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [07:03:20] PROBLEM - Puppet run on deployment-tmh01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [07:03:26] PROBLEM - Puppet run on deployment-secureredirexperiment is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [07:04:04] PROBLEM - Puppet run on deployment-kafka01 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [07:04:17] PROBLEM - Puppet run on deployment-elastic07 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [07:04:31] PROBLEM - Puppet run on deployment-redis01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [07:05:35] PROBLEM - Puppet run on deployment-db03 is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [07:06:05] PROBLEM - Puppet run on deployment-ms-fe01 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [07:07:01] PROBLEM - Puppet run on deployment-eventlogging04 is CRITICAL: CRITICAL: 50.00% of data above the critical threshold [0.0] [07:08:18] PROBLEM - Puppet run on deployment-db04 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [07:08:40] PROBLEM - Puppet run on deployment-ms-be02 is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [07:09:20] PROBLEM - Puppet run on deployment-elastic05 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [07:09:30] PROBLEM - Puppet run on deployment-cache-upload04 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [07:09:41] PROBLEM - Puppet run on deployment-memc05 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [07:09:47] PROBLEM - Puppet run on deployment-restbase01 is CRITICAL: CRITICAL: 40.00% of data above the critical threshold [0.0] [07:36:20] 10Gerrit, 07Regression: Automatic reviewer assignment does not work for certain repos - https://phabricator.wikimedia.org/T158844#3060330 (10Osnard) Seems to work. Thanks. [07:36:33] 10Gerrit, 07Regression: Automatic reviewer assignment does not work for certain repos - https://phabricator.wikimedia.org/T158844#3060331 (10Osnard) 05Open>03Resolved [08:35:39] RECOVERY - Check for valid instance states on labnodepool1001 is OK: nodepool state management is OK [08:36:36] !log nodepool deleted alien instances 541585 541586 and 541587 [08:36:38] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [08:40:06] (03CR) 10Hashar: Port git-changed-in-head to Python (031 comment) [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340181 (owner: 10Legoktm) [08:41:06] (03CR) 10Hashar: "I guess that is the pragmatic issue to work around ignoring linting of that file under Zend 5.5. Good enough for now I guess and should u" [integration/jenkins] - 10https://gerrit.wikimedia.org/r/340182 (https://phabricator.wikimedia.org/T136021) (owner: 10Legoktm) [12:30:51] hasharLunch: could you, after lunch, https://gerrit.wikimedia.org/r/#/c/339788/ ? tnx [12:36:25] (03CR) 10EddieGP: [C: 031] Whitelist user Matěj Suchánek [integration/config] - 10https://gerrit.wikimedia.org/r/339788 (owner: 10Urbanecm) [13:14:04] Hey, the topic states you're the home of MW-Vagrant, so I'll ask here, redirect me if necessary...: I've installed MW-Vagrant, took me a few hours until it worked but now everything seems to work perfectly fine except for the fact that loading localhost:8080 takes ~10-15 seconds for each pageview (which is quite annoying). Anybody knows how to fix that one? Networking seems to be a regular problem in Vagrant, but the answers I found online [13:14:04] didn't really help me. I've just reset my installation so that I'm starting over again from a fresh installation. [13:16:20] What spec is your machine? CPU? Ram? Storage (SSD/spinning)? [13:21:22] Quadcore i5-4590 @ 3.30GHz, 8GiB RAM. All four cores and 4GB RAM accesable by Vagrant. SSD for root partition (includes the vargrant installation in /opt) and hdd for /home (includes the directory with Vargrantfile, mediawiki and stuff in my home folder). Ubuntu 16.10 Host. [13:21:51] TabbyCat: doing :) [13:21:58] (03PS3) 10Hashar: Whitelist user Matěj Suchánek [integration/config] - 10https://gerrit.wikimedia.org/r/339788 (owner: 10Urbanecm) [13:22:09] (03CR) 10Hashar: [C: 032] Whitelist user Matěj Suchánek [integration/config] - 10https://gerrit.wikimedia.org/r/339788 (owner: 10Urbanecm) [13:23:13] (03Merged) 10jenkins-bot: Whitelist user Matěj Suchánek [integration/config] - 10https://gerrit.wikimedia.org/r/339788 (owner: 10Urbanecm) [13:24:38] (03PS2) 10Hashar: Experimental composer tests for mediawiki/vendor [integration/config] - 10https://gerrit.wikimedia.org/r/340241 (https://phabricator.wikimedia.org/T135161) [13:24:48] (03CR) 10Hashar: [C: 032] Experimental composer tests for mediawiki/vendor [integration/config] - 10https://gerrit.wikimedia.org/r/340241 (https://phabricator.wikimedia.org/T135161) (owner: 10Hashar) [13:26:21] (03Merged) 10jenkins-bot: Experimental composer tests for mediawiki/vendor [integration/config] - 10https://gerrit.wikimedia.org/r/340241 (https://phabricator.wikimedia.org/T135161) (owner: 10Hashar) [13:46:15] Reedy: You've seen my answer above? Forgot to mention you. [13:49:08] PROBLEM - Puppet run on buildlog is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [14:36:27] (03PS1) 10Zfilipin: WIP Upgrade to selenium-webdriver 3.2 [selenium] - 10https://gerrit.wikimedia.org/r/340317 (https://phabricator.wikimedia.org/T158074) [14:40:36] (03PS2) 10Zfilipin: Upgrade to selenium-webdriver 3.2 [selenium] - 10https://gerrit.wikimedia.org/r/340317 (https://phabricator.wikimedia.org/T158074) [14:54:51] the PHP community is so fragmented that it is not even fun : [14:54:51] :( [15:05:09] 10Continuous-Integration-Config, 10Wikidata, 13Patch-For-Review, 03Wikidata-Sprint: Fatal error: Call to undefined function Wikibase\Client\Tests\RecentChanges\both() - on jenkins - https://phabricator.wikimedia.org/T158674#3061219 (10WMDE-leszek) [15:38:58] how is t157674 doing hashar ? [15:44:40] RainbowSprinkles upstream are merging external-id's into a git repo instead of db. I have no idea if they will do it for ReviewDB but they have done it for NoteDB. We will want to make sure that T152640 does not happen again if or when we upgrade to gerrit 2.14 :) [15:44:40] T152640: Cannot log into Gerrit as of recent upgrade - https://phabricator.wikimedia.org/T152640 [16:27:18] 10Continuous-Integration-Config, 10Wikidata, 13Patch-For-Review, 03Wikidata-Sprint: Fatal error: Call to undefined function Wikibase\Client\Tests\RecentChanges\both() - on jenkins - https://phabricator.wikimedia.org/T158674#3061507 (10hashar) > But we can't update composer since we need PHP 5.5 support :-(... [16:27:32] 10Continuous-Integration-Infrastructure, 07Composer, 13Patch-For-Review: Upgrade integration/composer to 1.3.2 stable - https://phabricator.wikimedia.org/T125343#1985014 (10hashar) [16:28:33] 10Continuous-Integration-Config, 103d, 06Editing-Department, 06Multimedia: Set up CI for the 3D extension - https://phabricator.wikimedia.org/T159243#3061518 (10Jdforrester-WMF) [16:31:40] (03PS3) 10Hashar: Update composer to 1.1.0 with composer 1.1.0/PHP 5.5 [integration/composer] - 10https://gerrit.wikimedia.org/r/339645 (https://phabricator.wikimedia.org/T125343) [16:40:25] paladox: I swear to christ, storing everything in a git repo is such a terrible idea.... [16:40:36] Yeh [16:40:39] WHAT IS WRONG WITH A RDBMS? [16:40:41] it is a performance issue too [16:40:50] What is a RDBMS? [16:41:15] relational database management system [16:41:19] (a database) [16:41:22] Oh [16:41:37] Nothings wrong with it [16:41:38] it's probaly google likes using a repo then a db [16:42:23] Yeah well, it's a silly thing to like ;-) [16:42:39] lol, it's also a performance problem since gerrit-review is so slow [16:42:52] including trying to search for reviewers takes a few secs [16:46:30] RainbowSprinkles apparently they never hashed the passwords in http git clone. [16:46:38] Not even sure if it effects us. [16:46:53] And not sure if it also effects logging in too. [16:46:57] effects = affects. [16:48:32] It doesn't affect logging in, no [16:48:43] The http passwords can't be hashed, as you need to be able to show them to users [16:48:44] Ok :) [16:48:54] You could encrypt/decrypt them, but they don't do that :) [16:50:37] RainbowSprinkles we wont need to package bouncy castle any more in gerrit 2.14 :), they have built it in [16:56:49] that's nice [16:57:06] i remember when we had to upgrade that [16:58:16] That's good indeed [16:58:32] One less piece of junk for us to worry about :) [16:59:39] Yep [16:59:44] paladox: I kinda wish there was a plugins.directory setting like there is cache.directory [16:59:56] +1 to that. [17:00:08] If that existed, I could swap plugins to scap3 easy [17:00:41] lol, Maybe that could be easy to implement in gerrit? [17:00:49] Or is it hard coded in a lot of places? [17:01:10] I *think* it should be obtainable via SitePaths or whatever it's called [17:01:19] * RainbowSprinkles fires up eclipse and looks [17:02:08] lol [17:05:25] i found this [17:05:25] https://github.com/gerrit-review/gerrit/blob/49df12cb7da00f9298d8a37e231d55ecc83fa0c5/gerrit-pgm/src/main/java/com/google/gerrit/pgm/init/InitPlugins.java [17:05:25] Yep, it comes from SitePaths [17:05:25] site.plugin_path [17:05:26] Er, plugins_dir [17:05:26] Oh [17:05:37] ah, we could put that under a config [17:05:38] https://github.com/gerrit-review/gerrit/search?utf8=✓&q=plugins_dir&type=Code [17:06:08] Bleh, cache_dir isn't defined there [17:06:09] RainbowSprinkles or you could just symblink plugins dir to some where else. [17:06:10] I wonder.... [17:07:14] * paladox looks for how to define configs in gerrit [17:07:35] Well, I'm not sure how easy this is [17:07:44] SiteConfiguration isn't injected into SitePaths [17:07:48] It's a bunch of static junk [17:08:03] I'm curious how cache.directory gets used then [17:08:14] * RainbowSprinkles goes spelunking [17:08:15] oh [17:08:21] lol [17:08:35] This should be easyer to implement in polygerrit [17:08:56] though we doint want to do that yet as it will be a whole different type of plugin [17:09:26] Right now I'm wondering how much longer they'll use bazel :p [17:10:10] lol [17:10:10] RainbowSprinkles i find bazel to be the same as buck, ie i mean some of the commands [17:10:23] You can also install the debs :) [17:11:14] Though do note that it is harder to implement deps in the plugins now as you need a WORKSPACE file. [17:11:15] I was fine with maven before upstream decided they had to be different (from the rest of the java world) and not use it ;-) [17:11:22] lol [17:11:37] bazel is fast [17:12:20] Upstream didn't like maven because it has a tendency to err on the side of caution and be slower [17:12:22] ie: "This dependency chain *might* have changed, lets recompile just in case" [17:12:27] lol [17:12:45] But bazel seems to be more on the unstable side with tests. [17:13:05] RainbowSprinkles bingo https://github.com/gerrit-review/gerrit/blob/49df12cb7da00f9298d8a37e231d55ecc83fa0c5/gerrit-server/src/main/java/com/google/gerrit/server/config/GerritOptions.java [17:13:21] thats implemented in gerrit-server so we can implement it in the site thingy [17:13:38] That's not what we want exactly [17:13:41] oh [17:13:42] That's mostly for polygerrit [17:13:53] lol woops [17:14:40] Right namespace, but not that class [17:15:17] GcConfig, AuthConfig, PluginConfig, etc etc etc [17:15:21] Class per config section [17:15:33] (welcome to Java) [17:15:37] oh [17:15:38] lol [17:16:09] Java: when in doubt, add another class! [17:16:10] https://github.com/gerrit-review/gerrit/blob/49df12cb7da00f9298d8a37e231d55ecc83fa0c5/gerrit-server/src/main/java/com/google/gerrit/server/config/PluginConfig.java [17:16:10] :p [17:16:13] lol [17:17:13] RainbowSprinkles they now enforce the google-java-format upstream [17:17:48] They broke git blame by doing that [17:18:57] bingo, httpHeader = cfg.getString("plugins", null, "directory"); [17:20:18] Holy *crap* bazel eats up all my cpu [17:20:36] Machine....crawling....to......halt..... [17:21:18] lol [17:21:19] lol [17:21:37] it causes my mac to make a loud noise [17:21:38] it's the fan [17:21:47] Oh yeah, the fan's a-going [17:22:08] 92% usr [17:22:11] o_O [17:22:13] lollss [17:22:32] Are you building gerrit? [17:22:35] or the plugins [17:22:45] Full release w/ plugins [17:22:51] Oh :) [17:22:51] Haven't tested bazel yet, wanted to try [17:22:58] it is really good [17:23:03] though it can use alot of cpu [17:23:06] and ram [17:23:37] you will find release.war under bazel* [17:23:47] i forgot the actual path as i always do bazel* [17:24:01] Probably bazel-out/ [17:24:05] no [17:24:10] it's in bazel-bin [17:24:11] i think [17:24:23] plugins are in bazel-gen/plugins/ [17:24:29] Ah ok [17:24:30] got it [17:24:53] Yep, it's confusing the two different paths. [17:26:01] I recently converted a heep ton of gerrit plugins to the new format. [17:32:43] RainbowSprinkles i've crafted this https://gerrit-review.googlesource.com/#/c/98775/ patch. [17:32:48] it;s just a commit msg. [17:37:09] It now has content, though all it is doing is adding a config [17:49:58] RainbowSprinkles give this https://gerrit-review.googlesource.com/#/c/98775/ a try :) [17:50:07] it implements plugins.directory [17:50:11] :) [17:53:14] brb in a min [17:58:51] thcipriani: once we have a container build for mathoid, I am pretty sure yuvi can give us the magic command to run it using rkt [17:59:40] :) [17:59:41] and we can simulate the whole k8s system with something like: rkt --run ./mathoid-image-39039E9.image -- cd /mathoid && ./tests.sh [18:00:21] just djfinining how we describe the image build steps + requirements is going to take us a good chunk of time [18:00:24] getting the container built I don't think is too much of an issue. Getting it built in a sane and general way might be. [18:00:29] heck we could even use puppet to provision it :} [18:01:03] guess we will want to know a bit more about the images available on the docker registry [18:01:11] there is certainly some base one for jessie [18:01:17] yeap [18:01:47] we'll just need to find out how to define a core, build steps, and requirements in such a way that it is easy to modify, but still produces sane images [18:01:51] what worry me is [18:02:00] which parts will be defined in the image definition and which one will be in the centralized puppet.git [18:02:07] there are definitely jenkins plugins that are pretty close to what we need. [18:02:22] yup [18:03:06] yeah, I'm not too clear on that at this point. And it's still a long ways off, but I'm guessing that the puppet footprint for services that move to a deployment pipeline will mainly concern itself with configuration. [18:03:39] I sense lot of talks and exchanges are going to happen [18:03:53] maybe we will manage to gather people around some kind of consensus for the hackathon [18:04:08] whatever is needed to support the service as it has been built: just like the things that we have running on the jvm [18:04:34] we will find out. Place is closing down, I am committing back home [18:04:38] there is an application that is some kind of binary artifact and there are other pieces :) [18:04:45] yup, sounds good :) [18:04:59] wget https://releases.wikimedia.org/wikimedia/mathoid/latest | sudo bash [18:05:18] sounds legit [18:05:24] sold [18:05:24] and secure [18:05:27] :) [18:05:51] poke me about ci-staging either via tasks or mail [18:06:00] I will not be much around during evening this weeks [18:06:14] ok, will add you to things on phab as needed. [18:06:21] :} [18:06:21] * hashar vanishes [18:06:44] that *was* surprisingly abrupt :) [18:13:21] im back [18:16:37] RainbowSprinkles /me trys my patch for plugin directory [18:16:38] :) [18:48:22] can anything be done about the speed of jenkins-bot? [18:48:52] i know nodepool and all .. but it's worse again [18:50:13] i really can't wait for it that long but i also don't want us to do manual V+2 all the time [18:51:42] wants to just throw more dedicated hardware at it or something.. [18:58:06] my understanding is that force merging makes zuul a bit upset in some way I'm unclear about. It does prioritize the g+s queue, so if you're merging that should be the first queue that is allocated instances. [18:58:41] obviously when there are a lot of patches being merged, that takes up all the instances. IIRC we're capped at 20 currently. [18:58:43] Zuul's just got a bunch of patches in the queue, it's moving along just fine [18:58:45] * RainbowSprinkles shrugs [19:01:27] well.. i rebased at 10:38 and got the V+2 at 10:51. if you go do something else in that time and somebody else won the "race" before you, the next rebase follows and it adds up. so people start to do manual V+2 all the time which contradicts the whole point of having tests in the first place [19:02:39] i did not force-merge it, i try hard to avoid it and click rebase, switch to a different task, then come back in the right moment [19:03:00] it really adds upp though and losing focus [19:21:14] Sorry :( CI is annoyingly slow when there are a lot of patches. We are looking at medium-term solutions to speeding things up. I don't think there is any short term fix since the route we were on using nodepool is no longer a long-term solution. [19:31:25] thcipriani: thank you, it's good to know there are thoughts about a medium-term solution. i have heard some about the nodepool limitations, yea. it did get a bit faster again too. like you said it's changing throughout the day. it's just periods of slowing down [19:33:01] yeah, it certainly ebbs and flow :\ [19:33:05] s [19:33:21] https://phabricator.wikimedia.org/T140297 might be the most relevant ticket in this instance [19:34:37] eh, actually that may be a tangential but not entirely unrelated issue. [19:35:55] alrighty, yep [19:43:31] !log deployment-puppetmaster02 puppetmaster running again, apache2 was refusing to start with: Invalid command 'SSLOpenSSLConfCmd' -- installed apache from wmf repo instead of debian fixed it [19:43:34] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [19:46:24] Project beta-scap-eqiad build #144399: 04FAILURE in 1 min 23 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/144399/ [19:47:00] ^ host key failures, fixing [19:50:29] 10Continuous-Integration-Config, 06Operations, 13Patch-For-Review: Create a basic RSpec unit test for operations/puppet - https://phabricator.wikimedia.org/T78342#3062167 (10hashar) It has taken ages but finally we have some basic setup for running rspec-puppet tests. Next steps will be: * adding some more... [19:52:51] RECOVERY - Puppet run on deployment-mathoid is OK: OK: Less than 1.00% above the threshold [0.0] [19:53:21] RECOVERY - Puppet run on deployment-kafka04 is OK: OK: Less than 1.00% above the threshold [0.0] [19:53:31] RECOVERY - Puppet run on deployment-logstash2 is OK: OK: Less than 1.00% above the threshold [0.0] [19:53:47] RECOVERY - Puppet run on deployment-cache-text04 is OK: OK: Less than 1.00% above the threshold [0.0] [19:54:27] RECOVERY - Puppet run on deployment-mediawiki05 is OK: OK: Less than 1.00% above the threshold [0.0] [19:54:35] RECOVERY - Puppet run on deployment-parsoid09 is OK: OK: Less than 1.00% above the threshold [0.0] [19:54:42] RECOVERY - Puppet run on deployment-redis02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:55:26] RECOVERY - Puppet run on deployment-conf03 is OK: OK: Less than 1.00% above the threshold [0.0] [19:55:34] RECOVERY - Puppet run on deployment-elastic06 is OK: OK: Less than 1.00% above the threshold [0.0] [19:56:10] RECOVERY - Puppet run on deployment-jobrunner02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:56:52] Project beta-scap-eqiad build #144400: 04STILL FAILING in 1 min 59 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/144400/ [19:57:04] RECOVERY - Puppet run on deployment-apertium02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:57:09] RECOVERY - Puppet run on deployment-salt02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:57:12] beta-scap-eqiad: blech, still 2 hosts missing :\ [19:57:27] RECOVERY - Puppet run on deployment-tin is OK: OK: Less than 1.00% above the threshold [0.0] [19:57:53] RECOVERY - Puppet run on deployment-fluorine02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:58:14] RECOVERY - Puppet run on deployment-zotero01 is OK: OK: Less than 1.00% above the threshold [0.0] [19:58:26] RECOVERY - Puppet run on deployment-mcs01 is OK: OK: Less than 1.00% above the threshold [0.0] [19:58:32] RECOVERY - Puppet run on deployment-pdfrender02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:58:56] RECOVERY - Puppet run on deployment-phab01 is OK: OK: Less than 1.00% above the threshold [0.0] [19:59:10] RECOVERY - Puppet run on deployment-phab02 is OK: OK: Less than 1.00% above the threshold [0.0] [19:59:22] RECOVERY - Puppet run on deployment-changeprop is OK: OK: Less than 1.00% above the threshold [0.0] [19:59:28] RECOVERY - Puppet run on deployment-zookeeper01 is OK: OK: Less than 1.00% above the threshold [0.0] [19:59:28] RECOVERY - Puppet run on deployment-urldownloader is OK: OK: Less than 1.00% above the threshold [0.0] [19:59:46] RECOVERY - Puppet run on deployment-sca03 is OK: OK: Less than 1.00% above the threshold [0.0] [20:01:04] RECOVERY - Puppet run on deployment-ores-redis is OK: OK: Less than 1.00% above the threshold [0.0] [20:01:57] RECOVERY - Puppet run on deployment-prometheus01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:02:03] RECOVERY - Puppet run on deployment-copper is OK: OK: Less than 1.00% above the threshold [0.0] [20:02:17] RECOVERY - Puppet run on deployment-trending01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:02:43] RECOVERY - Puppet run on deployment-puppetdb01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:02:59] RECOVERY - Puppet run on deployment-mira is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:03] RECOVERY - Puppet run on deployment-kafka05 is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:05] RECOVERY - Puppet run on deployment-aqs01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:14] RECOVERY - Puppet run on deployment-mediawiki04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:20] RECOVERY - Puppet run on deployment-eventlogging03 is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:26] RECOVERY - Puppet run on deployment-puppetmaster02 is OK: OK: Less than 1.00% above the threshold [0.0] [20:03:48] RECOVERY - Puppet run on deployment-mx is OK: OK: Less than 1.00% above the threshold [0.0] [20:04:32] RECOVERY - Puppet run on deployment-stream is OK: OK: Less than 1.00% above the threshold [0.0] [20:04:36] RainbowSprinkles i found this https://github.com/gerrit-review/gerrit/search?utf8=✓&q=plugins_dir&type=Code [20:05:53] Yeah, but it hardcodes the path [20:06:31] Yeh, im trying to figoure out how i can make plugin_path a Path [20:06:36] because it keeps failing [20:06:53] Project beta-scap-eqiad build #144401: 04STILL FAILING in 1 min 58 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/144401/ [20:07:17] RECOVERY - Puppet run on deployment-sca01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:07:17] RECOVERY - Puppet run on deployment-sentry01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:07:33] RECOVERY - Puppet run on deployment-poolcounter04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:07:37] RECOVERY - Puppet run on deployment-pdf01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:08:05] RECOVERY - Puppet run on deployment-ms-be01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:08:09] RECOVERY - Puppet run on deployment-ircd is OK: OK: Less than 1.00% above the threshold [0.0] [20:08:11] i could use .toPath() [20:08:23] beta-scap-eqiad should be fixed now, next time around. [20:08:29] RECOVERY - Puppet run on deployment-secureredirexperiment is OK: OK: Less than 1.00% above the threshold [0.0] [20:08:31] RECOVERY - Puppet run on deployment-sca02 is OK: OK: Less than 1.00% above the threshold [0.0] [20:09:05] RECOVERY - Puppet run on deployment-kafka01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:10:38] RECOVERY - Puppet run on deployment-db03 is OK: OK: Less than 1.00% above the threshold [0.0] [20:11:06] RECOVERY - Puppet run on deployment-ms-fe01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:11:08] RECOVERY - Puppet run on deployment-restbase02 is OK: OK: Less than 1.00% above the threshold [0.0] [20:11:14] RECOVERY - Puppet run on deployment-kafka03 is OK: OK: Less than 1.00% above the threshold [0.0] [20:11:16] RECOVERY - Puppet run on deployment-memc04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:12:00] RECOVERY - Puppet run on deployment-eventlogging04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:12:48] I get [20:12:48] gerrit-server/src/main/java/com/google/gerrit/server/config/SitePaths.java:80: error: incompatible types: PluginConfig cannot be converted to Path [20:13:21] RECOVERY - Puppet run on deployment-tmh01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:13:43] RECOVERY - Puppet run on deployment-ms-be02 is OK: OK: Less than 1.00% above the threshold [0.0] [20:14:17] RECOVERY - Puppet run on deployment-elastic07 is OK: OK: Less than 1.00% above the threshold [0.0] [20:14:21] RECOVERY - Puppet run on deployment-elastic05 is OK: OK: Less than 1.00% above the threshold [0.0] [20:14:31] RECOVERY - Puppet run on deployment-cache-upload04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:14:31] RECOVERY - Puppet run on deployment-redis01 is OK: OK: Less than 1.00% above the threshold [0.0] [20:14:41] RECOVERY - Puppet run on deployment-memc05 is OK: OK: Less than 1.00% above the threshold [0.0] [20:17:12] Yippee, build fixed! [20:17:12] Project beta-scap-eqiad build #144402: 09FIXED in 2 min 14 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/144402/ [20:18:16] RECOVERY - Puppet run on deployment-db04 is OK: OK: Less than 1.00% above the threshold [0.0] [20:18:24] RECOVERY - Puppet run on deployment-mediawiki06 is OK: OK: Less than 1.00% above the threshold [0.0] [20:19:46] RECOVERY - Puppet run on deployment-restbase01 is OK: OK: Less than 1.00% above the threshold [0.0] [21:36:43] (03CR) 10Reedy: "1.3.2 is out... And https://gerrit.wikimedia.org/r/339599 was regenerated using 1.3.2" [integration/composer] - 10https://gerrit.wikimedia.org/r/339645 (https://phabricator.wikimedia.org/T125343) (owner: 10Hashar) [22:34:33] RainbowSprinkles the only thing that they havent migrated from buck is the license field in maven_package [22:34:44] maven_jar i mean [22:34:46] to bazel [22:44:11] (03CR) 10Hashar: "I am being conservative and just do a 1.1.0-RC..1.1.0 bump so we bring in less changes. My hope is that this way the change has less surf" [integration/composer] - 10https://gerrit.wikimedia.org/r/339645 (https://phabricator.wikimedia.org/T125343) (owner: 10Hashar) [23:00:53] thcipriani: good evening. Jenkins/puppet I replied on https://phabricator.wikimedia.org/T159286#3063057 :d [23:00:56] I wasn't waiting for your task to show up, one of my kid is sick :\ [23:01:18] part of the history is that at some point I used the same puppet class on labs [23:01:25] the instance got deleted two or three time by mistake [23:01:27] Sorry to hear that :( [23:01:30] and eventually I gave up [23:01:46] thanks for the reply [23:01:47] then some more refactoring happened in puppet + random patches and the role classes no more apply [23:02:03] ::jenkins should be enough [23:02:21]