[00:00:07] New patchset: Dzahn; "remove misc::download-mediawiki from kaulen because it's either supposed to be on swift or on a new download host in eqiad, but not on the bugzilla server and not in Tampa and it wasn't used anyways. just added download.mediawiki.org to Apache conf so tha" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72664 [00:01:13] New review: Dzahn; "per RT-1839 not on kaulen and was empty dir" [operations/puppet] (production) C: 2; - https://gerrit.wikimedia.org/r/72664 [00:01:14] Change merged: Dzahn; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72664 [00:04:28] New patchset: Dzahn; "remove non-root users from kaulen since it's not used as download server" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72666 [00:05:36] New review: Dzahn; "note that bugzilla is also going to move away from kaulen anyways" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72666 [00:31:52] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [00:32:42] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 7.453 second response time [00:45:25] !log updated Parsoid to d0e3603 [00:45:34] Logged the message, Master [00:45:36] RECOVERY - Parsoid on wtp1021 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.003 second response time [00:46:06] RECOVERY - Parsoid on wtp1011 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.010 second response time [00:46:06] RECOVERY - Parsoid on wtp1017 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.003 second response time [01:55:59] !log tstarling synchronized php-1.22wmf9/includes/WikiPage.php [01:56:09] Logged the message, Master [01:56:30] !log tstarling synchronized php-1.22wmf9/includes/api/ApiPurge.php [01:56:39] Logged the message, Master [02:13:46] PROBLEM - Puppet freshness on manutius is CRITICAL: No successful Puppet run in the last 10 hours [02:14:13] !log LocalisationUpdate completed (1.22wmf9) at Tue Jul 9 02:14:12 UTC 2013 [02:14:20] New patchset: GWicke; "Increase Parsoid backend timeout to 5 minutes" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72681 [02:14:22] Logged the message, Master [02:22:07] AzaToth: Who's calling me Mr. McBride? [02:26:55] !log LocalisationUpdate completed (1.22wmf8) at Tue Jul 9 02:26:54 UTC 2013 [02:27:04] Logged the message, Master [02:38:31] !log LocalisationUpdate ResourceLoader cache refresh completed at Tue Jul 9 02:38:31 UTC 2013 [02:38:41] Logged the message, Master [02:50:47] PROBLEM - DPKG on mc15 is CRITICAL: Timeout while attempting connection [02:51:38] RECOVERY - DPKG on mc15 is OK: All packages OK [02:52:33] Elsie: on WO [02:52:42] Oh, heh. [04:15:40] !log tstarling synchronized php-1.22wmf8/includes/WikiPage.php [04:15:49] Logged the message, Master [04:16:14] !log tstarling synchronized php-1.22wmf8/includes/api/ApiPurge.php [04:16:23] Logged the message, Master [05:30:29] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [05:31:28] PROBLEM - DPKG on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [05:33:18] RECOVERY - DPKG on searchidx1001 is OK: All packages OK [05:37:30] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [05:40:29] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [05:43:29] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [07:24:59] PROBLEM - Puppet freshness on erzurumi is CRITICAL: No successful Puppet run in the last 10 hours [07:24:59] PROBLEM - Puppet freshness on lvs1004 is CRITICAL: No successful Puppet run in the last 10 hours [07:24:59] PROBLEM - Puppet freshness on lvs1005 is CRITICAL: No successful Puppet run in the last 10 hours [07:24:59] PROBLEM - Puppet freshness on lvs1006 is CRITICAL: No successful Puppet run in the last 10 hours [07:24:59] PROBLEM - Puppet freshness on mc15 is CRITICAL: No successful Puppet run in the last 10 hours [07:25:00] PROBLEM - Puppet freshness on virt1 is CRITICAL: No successful Puppet run in the last 10 hours [07:25:00] PROBLEM - Puppet freshness on virt3 is CRITICAL: No successful Puppet run in the last 10 hours [07:25:01] PROBLEM - Puppet freshness on virt4 is CRITICAL: No successful Puppet run in the last 10 hours [07:55:58] New review: Hashar; "fine to me." [operations/puppet] (production) C: 1; - https://gerrit.wikimedia.org/r/72666 [07:59:39] New review: Hashar; "Sorry I cant really review that, too many things to do already. My only recommendation would be to ..." [operations/apache-config] (master) - https://gerrit.wikimedia.org/r/62566 [08:06:17] New review: Mark Bergsma; "This should be done using a purge script, not varnishadm directly. Then that purge script can also c..." [operations/puppet] (production) C: -1; - https://gerrit.wikimedia.org/r/72653 [08:26:04] New patchset: ArielGlenn; ".gitignore, .gitreview, debian packaging files for mwbzutils" [operations/debs/mwbzutils] (master) - https://gerrit.wikimedia.org/r/72691 [08:36:44] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [08:37:35] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [08:42:52] Change merged: ArielGlenn; [operations/debs/mwbzutils] (master) - https://gerrit.wikimedia.org/r/72691 [08:43:13] !log nikerabbit synchronized php-1.22wmf9/extensions/UniversalLanguageSelector/ 'ULS to master' [08:43:24] Logged the message, Master [08:52:02] !log nikerabbit synchronized php-1.22wmf8/extensions/UniversalLanguageSelector/ 'ULS to master' [08:52:10] Logged the message, Master [08:52:46] New patchset: Nikerabbit; "ULS deployment phase 5" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/71971 [08:53:08] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/71971 [08:55:38] !log nikerabbit synchronized wmf-config/InitialiseSettings.php 'ULS phase 5' [08:55:46] Logged the message, Master [09:21:22] New patchset: Nikerabbit; "Disable ULS on ml.*" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72702 [09:28:34] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72702 [09:29:01] !log nikerabbit synchronized php-1.22wmf8/extensions/UniversalLanguageSelector/ 'ULS to master' [09:31:52] !log nikerabbit synchronized php-1.22wmf9/extensions/UniversalLanguageSelector/ 'ULS to master' [09:33:30] !log nikerabbit synchronized wmf-config/InitialiseSettings.php 'Bug 51019' [09:33:40] Logged the message, Master [09:42:10] I am having trouble with a user who seems to have a labs account, but is not visible to gerrit. [09:42:32] Could someone with access to LDAP please check whether ther problem is on the gerrit side, or the LDAP side? [09:43:35] qchris: what do you mean "visible to gerrit"? [09:44:01] p858snake|l: Gerrit complains that the user does not exist ... which should mean that it's not in LDAP. [09:44:14] as in logging in? commiting? [09:44:17] p858snake|l: However, I cannot check whether or not the user is in ldap. [09:44:29] p858snake|l: As in 'Trying to add the user to a group' [09:45:08] p858snake|l: Neither does gerrit autosuggest the user, nor does gerrit allow to add directly. [09:50:14] PROBLEM - Host mw72 is DOWN: PING CRITICAL - Packet loss = 100% [09:50:44] RECOVERY - Host mw72 is UP: PING OK - Packet loss = 0%, RTA = 26.63 ms [09:51:11] qchris: wikitech/labs creates the accounts in ldap automatically, so it should be there [09:51:24] make sure they are in the shell group on wiki maybe [09:51:58] (if they aren't, they shouldn't be able to currently push to gerrit, so thats a easy check) [09:52:41] p858snake|l: How can I check if they are in the shell group on wiki? [09:53:45] whats the username, I will play around since I havn't looked for awhile [09:54:34] p858snake|l: It shows "(shell)" for the user on https://wikitech.wikimedia.org/w/index.php?title=Special%3AListUsers [09:54:52] p858snake|l: So I guess, that means he's in the shell group :-/ [09:55:12] yes [09:55:26] Ok. Thanks. [09:55:38] qchris: bug ^demon or ryan most likely [09:56:08] p858snake|l: Yes, I'll do that. Thanks. [10:11:48] New patchset: ArielGlenn; "deployment script: better error handling, make correct remote dirs" [operations/dumps] (ariel) - https://gerrit.wikimedia.org/r/72708 [10:20:50] Change merged: ArielGlenn; [operations/dumps] (ariel) - https://gerrit.wikimedia.org/r/72708 [10:37:26] PROBLEM - SSH on cp3004 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [10:37:36] PROBLEM - Varnish HTTP upload-backend on cp3004 is CRITICAL: Connection timed out [10:37:45] PROBLEM - Varnish traffic logger on cp3004 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [10:37:45] PROBLEM - Varnish HTCP daemon on cp3004 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [10:43:25] RECOVERY - SSH on cp3004 is OK: SSH OK - OpenSSH_5.9p1 Debian-5ubuntu1.1 (protocol 2.0) [10:43:35] RECOVERY - Varnish traffic logger on cp3004 is OK: PROCS OK: 2 processes with command name varnishncsa [10:43:36] RECOVERY - Varnish HTCP daemon on cp3004 is OK: PROCS OK: 1 process with UID = 111 (vhtcpd), args vhtcpd [11:00:45] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [11:01:35] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.132 second response time [11:06:30] New review: Faidon; "Considering the ongoing discussions about database backups/xtrabackup, perhaps the MySQL bpipe plugi..." [operations/puppet] (production) - https://gerrit.wikimedia.org/r/70840 [11:14:02] New review: Parent5446; "(1 comment)" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/69982 [11:18:37] New review: Faidon; "That's really nice work, Ori. Very well documented and styled, plus the upstart bits are nice. I onl..." [operations/puppet] (production) C: -1; - https://gerrit.wikimedia.org/r/71927 [11:21:27] New review: QChris; "I have no idea how the github projects get generated.." [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72130 [11:43:37] New patchset: DixonD; "Settings for categories created by Extension:Babel for Ukrainian Wikisource." [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72713 [11:47:33] !log apt: updating to ceph 0.66 [11:47:43] Logged the message, Master [11:48:14] New patchset: DixonD; "Settings for categories created by Extension:Babel for Ukrainian Wikisource." [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72713 [12:14:11] PROBLEM - Puppet freshness on manutius is CRITICAL: No successful Puppet run in the last 10 hours [12:32:50] manybubbles: hey [12:33:00] paravoid: hey! [12:33:04] manybubbles: https://gerrit.wikimedia.org/r/#/c/72522/ [12:33:34] plus we should probably merge that javadoc cleanup too [12:34:51] paravoid: I'll read the commit. you may want to have a look at all the pending changes for operations/debs/jmxtrans - I believe I have one for .gitreview as well [12:34:51] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [12:35:04] oh I didn't see that [12:36:01] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [12:37:44] New review: Manybubbles; "Most things of the commit is nice cleanup. The meat is merging preinst and postinst. All changes s..." [operations/debs/jmxtrans] (master) C: 1; - https://gerrit.wikimedia.org/r/72522 [12:38:09] manybubbles: I had those as PS5 on your original commit [12:38:29] but you accidentally pushed PS6 based on PS4 and these were lost [12:38:32] and I didn't notice [12:38:45] paravoid: Sorry! I'm still getting used to gerrit. [12:39:00] oh no worries [12:49:09] New patchset: Hashar; "rake wrapper to run puppet module tests" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72721 [12:52:34] if you wanna try out spec unit test in puppet, see 72721 ^^^^ [12:55:37] hashar: so... [12:58:48] hashar: any progress? [12:59:14] AzaToth: hi [13:01:07] New review: AzaToth; "(1 comment)" [operations/debs/jmxtrans] (master) - https://gerrit.wikimedia.org/r/72522 [13:01:30] hashar: you saw they've merged the TAP thingi now? [13:01:52] so now you can use jenkins-build [13:02:05] just need to update it [13:03:02] !log touched and synced extensions/Wikibase/lib/resources/wikibase.ui.SiteLinksEditTool.js on php-1.22wmf8 and php-1.22wmf9 [13:03:02] !log hashar synchronized php-1.22wmf8/extensions/Wikibase/lib/resources/wikibase.ui.SiteLinksEditTool.js [13:03:10] Logged the message, Master [13:03:19] Logged the message, Master [13:03:30] !log hashar synchronized php-1.22wmf9/extensions/Wikibase/lib/resources/wikibase.ui.SiteLinksEditTool.js [13:03:39] Logged the message, Master [13:03:43] orly [13:19:45] !log upgraded ceph to 0.66 [13:19:55] Logged the message, Master [13:22:26] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [13:23:17] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 5.028 second response time [13:27:26] paravoid: hi [13:27:35] hi. [13:27:51] paravoid: I'm trying to fix a lintian problem related to RPATH [13:28:19] is this about dclass? [13:28:45] you still haven't reacted/replied to about 20% of my review :) [13:29:09] paravoid: the SONAME right ? [13:29:14] not just that [13:29:19] also installing from .libs [13:29:23] and overriding make install completely [13:29:39] paravoid: about installing from .libs, wrote a comment, that the path will be arch-dependent [13:29:51] paravoid: can you give me some tips please on how to handle that in a more generic way ? [13:29:58] like perhaps an $ARCH variable or something ? [13:30:43] what do you mean? [13:33:04] paravoid: so you said "don't use .libs, use debian/tmp" right ? [13:33:29] paravoid: but the path to debian/tmp is build-area/dclass-2.0.14/debian/tmp/usr/lib/x86_64-linux-gnu/ [13:33:45] that is correct [13:33:45] paravoid: the "x86_64-linux-gnu" part of that path is arch-dependent [13:33:58] yes, that's how it's supposed to be [13:34:33] putting the lib in the root of /usr/lib is wrong [13:34:40] paravoid: ok, my question is, in my *.install I'll have to use a path like debian/tmp/usr/lib/$ARCH/ [13:34:56] paravoid: is there such a variable like $ARCH and can I use variables like that inside *.install files ? [13:35:24] paravoid: I intend to build for both 32-bit and 64-bit [13:35:51] average: why 32 bit as well? that does not seem necessary [13:35:55] echo 'usr/lib/*/libdclassjni*so*' > debian/libdclass-jni.install [13:35:59] should be enough [13:37:26] you're currently installing the library under /usr/lib/, e.g. /usr/lib/libfoo.so. that's wrong, it should be /usr/lib//libfoo.so [13:37:35] you're also installing *from* .libs which is also very wrong [13:38:26] ok, will switch to getting stuff from debian/tmp [13:38:55] nod [13:41:22] one more thing [13:41:33] I got this lintian error about RPATH [13:42:57] paravoid: what do you mean above by "" ? [13:43:25] the lintian error is ===> E: libdclass0-jni: binary-or-shlib-defines-rpath usr/lib/libdclassjni.so.0.0.0 /home/user/wikistats/build-area/dclass-2.0.14/.libs [13:44:07] I don't know what to do about it, read some pages, tried to get rid of -Wl and -Wall flags in the Makefile.am , the lintian error above persists [13:44:26] try using debian/tmp [13:44:32] pretty sure it's going to be gone [13:44:52] ok, what about "" ? [13:45:51] x86-64 - linux - gnu [13:45:53] that's the triplet [13:47:29] ok [13:47:36] thank you [13:48:26] three parts [13:48:26] PROBLEM - Disk space on virt6 is CRITICAL: DISK CRITICAL - free space: /var/lib/nova/instances 38845 MB (3% inode=99%): [13:49:09] see https://wiki.debian.org/Multiarch/Tuples [13:49:34] technically the path is not the GNU triplet [13:49:44] but something that looks like it, that page explains it further [13:49:49] I'm not sure if you care that much though :) [13:51:13] paravoid: I care, but want to get the package out also [13:52:25] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [13:53:15] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.124 second response time [13:56:12] paravoid: quick q: what's the status of debianizing librdkafka? [13:56:15] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [13:57:15] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [13:57:33] drdee: I haven't worked on it for a while [13:58:26] k, is there much left / [14:01:17] not really [14:01:38] we were going back and forward with Snaps on the 0.8 branch and all that [14:01:49] but that really just needs a decision, nothing more :) [14:01:55] what decisin? [14:02:11] New patchset: Ottomata; "Adding Christian Aistleitner account on analytics nodes. RT 5403" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72726 [14:02:49] New patchset: Ottomata; "Adding Christian Aistleitner account on analytics nodes. RT 5403" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72726 [14:03:41] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72726 [14:04:16] drdee, i'm not sure what their discussion was, but just with the kafka debianization, we can't really build the official deb until 0.8 is released [14:04:21] we can get it all ready [14:04:32] so that once it is we just build the .deb and tada done [14:04:43] k [14:06:06] paravoid: I'll move 0.8 to master [14:08:10] New patchset: Ottomata; "Fixing copy/paste error in admins.pp" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72727 [14:08:53] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72727 [14:09:38] Snaps: don't mean to pressure you, I can package a branch too [14:10:30] paravoid: thanks, but its okay, it is meant for master eventually anyway. [14:22:21] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [14:23:11] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.122 second response time [14:26:54] hashar, sorry, just sent you an invite by mistake [14:27:06] apparently I don't know how to set up a new hangoug. [14:27:09] hangout [14:27:15] is there booze at that event ? [14:27:26] if so I will be happy to take a plane to attend [14:28:35] wow, it's almost 17h ? [14:28:47] where does the time go [14:35:00] New patchset: Ottomata; "Puppetizing analytics udp2log instances" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72618 [14:35:13] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72618 [14:39:19] Change merged: Faidon; [operations/debs/jmxtrans] (wikimedia) - https://gerrit.wikimedia.org/r/71384 [14:39:21] !log stopping puppet on analytics1006, 1008 and 1009 to manually apply udp2log puppetization [14:39:31] Logged the message, Master [14:40:32] New review: Faidon; "(1 comment)" [operations/debs/jmxtrans] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/72522 [14:40:33] Change merged: Faidon; [operations/debs/jmxtrans] (master) - https://gerrit.wikimedia.org/r/72522 [14:41:57] New review: Faidon; "I never saw the point of .gitreview but I'm with merging it. I think though that you'd need a prebui..." [operations/debs/jmxtrans] (debian) C: -1; - https://gerrit.wikimedia.org/r/71373 [14:43:04] New patchset: Ottomata; "Fixing application of udp2log roles on proper hosts" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72729 [14:43:08] New review: Faidon; "Looks unused here too :) Thanks!" [operations/puppet] (production) C: 2; - https://gerrit.wikimedia.org/r/71127 [14:43:36] ottomata: heh, typos happen within puppet too :) [14:43:40] New patchset: Ottomata; "Fixing application of udp2log roles on proper hosts" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72729 [14:43:48] haha [14:43:50] yeah rigiht! [14:43:59] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72729 [14:50:36] Change merged: Andrew Bogott; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/71127 [14:52:24] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [14:53:14] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 1.930 second response time [14:55:53] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72613 [14:56:24] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [14:56:57] New patchset: Ottomata; "Removing quotes from libanon salt key in udp2log filter config" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72730 [14:57:14] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.126 second response time [14:57:34] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72730 [14:59:22] paravoid: you don't use git review? [14:59:50] !log maxsem synchronized wmf-config/InitialiseSettings.php [14:59:59] Logged the message, Master [15:00:20] I don't [15:00:51] lol [15:01:03] i never tried git reivew [15:01:16] so you manually push? [15:01:32] git push origin HEAD:refs/publish/foo [15:01:34] PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [15:04:35] jeremyb: heh [15:04:47] RECOVERY - RAID on searchidx1001 is OK: OK: State is Optimal, checked 4 logical device(s) [15:04:47] hashar, will you join our call? Alex sent you an invite. [15:05:03] ohh [15:05:25] RECOVERY - Disk space on analytics1006 is OK: DISK OK [15:07:02] pfr-master = push origin HEAD:refs/for/master [15:07:02] pfr-prod = push origin HEAD:refs/for/production [15:09:13] !log re-starting puppet on analytics1006,1008,1009 [15:09:22] Logged the message, Master [15:09:46] New patchset: AzaToth; "adding gitreview" [operations/debs/jmxtrans] (debian) - https://gerrit.wikimedia.org/r/71373 [15:10:08] paravoid: fixed [15:10:42] paravoid: never added that one before as I made it before the debianization was merged [15:11:18] paravoid: I assume you are too stubborn to allow yourself to try git review [15:11:44] ツ [15:14:04] I won't deny that [15:14:05] :) [15:14:11] * paravoid is upgrading desktop to wheezy [15:14:24] 1525 upgraded, 701 newly installed, 70 to remove and 4 not upgraded. [15:14:27] Need to get 1972 MB of archives. [15:14:30] "fun" [15:14:38] heh [15:15:47] paravoid: bne happy you are not using Arch Linux [15:16:03] paravoid: if you forget to upgrade during a month, you are fucked [15:17:03] (if you even suceeds in installing it, as they have no installer) [15:17:03] New review: Manybubbles; "This successfully gets .gitreview out of the source package. Is there a reason .gitreview needs to ..." [operations/debs/jmxtrans] (debian) C: 1; - https://gerrit.wikimedia.org/r/71373 [15:17:34] I didn't say out of the source package [15:17:34] manybubbles: depends on which branch it is on [15:17:40] I said gbp [15:18:09] paravoid: added debian/source/options to solve that [15:18:11] I don't remember the exact circumstances though [15:18:23] last time around I think we needed it in debian/gbp.conf [15:18:26] it's because it's not part of the upstream package [15:18:33] prebuild = rm -f .gitreview [15:18:51] paravoid: extend-diff-ignore = '^\.gitreview$' works fine [15:18:52] not sure though, I think I've it under source/options too [15:19:49] manybubbles: it's all about the concept of pristine upstream [15:20:06] which we though violate [15:20:11] but not that much ツ [15:20:46] anyway, cut have placed the .gitreview in the wikimedia branch, then the debian/source/options wouldn't be needed [15:21:58] it boils down to that anything in the debian dir/branch shouldn't modify hard anything outside the debian dir [15:22:26] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [15:22:50] the .gitreview thingi is a bit a problem then as it can be in the debian dir, and it needs to exists without running some other command [15:23:16] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.126 second response time [15:23:16] as most people uses git-review [15:23:30] only the few hardcore geeks does it manually [15:24:29] New patchset: Ottomata; "Adding icinga alerts for per topic kafka producers" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72733 [15:24:44] manybubbles: did you make the v242 tag, or is it upstream? [15:25:00] AzaToth: upstream iirc [15:25:01] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/72733 [15:25:28] then we could use upstream-tree=tag as normal [15:25:54] upstream-tree=branch is only needed when upstream has never made any tags, or we are following tip unconditionally [15:26:21] it is on https://github.com/jmxtrans/jmxtrans/tags so they made it. [15:26:31] i.e. if you can do "git describe", then tag is sufficient [15:27:26] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [15:27:50] AzaToth: ok - that makes sense now that we're using patches to change their build in the debian branch. It didn't make sense when I started because I didn't think that was how you were supposed to use git-buildpackage. [15:28:13] heh [15:28:19] it's understandable [15:28:19] AzaToth: though I believe we still remove their less than ideal debian directory in the wmf branch [15:28:43] that's a recommended way actually [15:28:49] if upstream ships a debian dir [15:30:16] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.125 second response time [15:32:13] I use git-review but don't use .gitreview files [15:32:18] i just manually add the gerrit remote [15:32:21] and run git-review -s [15:32:24] and from then on it just works [15:33:41] New patchset: MaxSem; "Don't redirect m.wikimediafoundation.org to the main site" [operations/apache-config] (master) - https://gerrit.wikimedia.org/r/72734 [15:35:14] New patchset: MaxSem; "Don't redirect m.wikimediafoundation.org to the main site" [operations/apache-config] (master) - https://gerrit.wikimedia.org/r/72734 [15:35:31] andrewbogott: the patch I was referring to is https://gerrit.wikimedia.org/r/#/c/72721/ [15:35:49] andrewbogott: that is basically your python wrapper from integration/jenkins.git but ported to Rake and in operations/puppet.git [15:37:20] hasharCall: That looks much more efficient! But now I'm troubled about the stage that checks things out from github... [15:37:33] (I mean, my test did that too of course.) [15:38:52] yeah I am not sure what the fixtures are :/ [15:39:00] one way would be to have them in our own repo [15:39:22] and skip the github dependency entirely, that is what the spec_standalone task is for [15:39:29] Yeah, that's probably what we should do. I'm trying to figure out what's in there. [15:39:51] New patchset: Matthias Mullie; "Enable auto-archive on enwiki" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/72735 [15:40:16] so hmm that is ton of .rb files :-] [15:40:32] and some facters [15:41:16] Presumably it's always the same… could just use a tarball? [15:41:21] andrewbogott: are you the one to ask a security question if csteipp isn't around? [15:41:32] matanya, probably not :) [15:41:37] who is? [15:41:46] paravoid maybe. [15:41:47] matanya: to me in private please [15:41:57] ah, there you go. [15:42:01] could point you to another person depending on the exact issue [15:42:02] :) [15:42:15] infrastucture or mediawiki? [15:43:48] matanya: several of us read u-s-a, there's no need to ping us everytime a USN gets released [15:44:19] thanks paravoid I asked csteipp about it, he sisn't know [15:44:24] *didn't [15:44:29] I have u-s-a on my inbox, don't worry [15:44:37] I'll stop. thanks for letting me know [15:44:50] oh don't get me wrong, it's appreciated [15:45:02] sure, i said that in a good way [15:45:07] hasharCall, one of the things that it checks out is stdlib and we already have a version of that in our puppet repo. [15:45:55] although maybe trying to reuse just makes it harder [15:46:05] andrewbogott: they might have a different version requirement for stdlib [15:46:14] * andrewbogott nods [15:46:45] paravoid: there should be Intonation in IRC :P [15:47:59] andrewbogott: so potentially we could use a snapshot of the github repositories and publish them in ops/puppet [15:48:23] andrewbogott: or use submodules and a specific sha1 that would be changed after review of the code [15:48:56] then adapt the rakefile patch to not use spec_prep (which fetch from github to prepare the fixtures) and simply call spec_standalone [15:50:54] hasharCall, how would the snapshot work? Would the whole tree be checked into the puppet repo? [15:51:27] yeah that is the problem [15:51:52] using submodule might work, but then you probably don't want the puppet master to fetch from them :D [15:52:06] awjr: hey, are you going to need this, or can this ticket be closed? https://rt.wikimedia.org/Ticket/Display.html?id=5267 [15:52:09] New patchset: AzaToth; "update build.xml" [operations/debs/jmxtrans] (master) - https://gerrit.wikimedia.org/r/72736 [15:52:09] New patchset: AzaToth; "Initialize git-dpm" [operations/debs/jmxtrans] (master) - https://gerrit.wikimedia.org/r/72737 [15:53:19] @notify binasher [15:53:19] I'll let you know when I see binasher around here [15:53:44] hasharCall, at the moment the rake tests check out those files once for every module. But nothing in that tree is changed, right? [15:54:03] So we could package them, install them someplace and just do everything with symlinks? [15:54:18] ohhh [15:54:29] do you mean debian packaging some puppet modules ? : -D [15:55:19] Yeah, just regard that whole 'fixtures' directory as a single package. [15:55:34] And then just have one copy of it on our system, for good. [15:56:08] It's kind of weird that it doesn't work like that already, which makes me wonder if I'm missing something [15:59:00] andrewbogott: the list of fetched out module sis http://paste.openstack.org/show/39823/ [16:00:02] andrewbogott: I am not sure what to do honestly. There are too many options :-] [16:00:06] paravoid, you might have an opinion about this. [16:00:32] The puppet spec tests currently check out the ^above^ list of puppet modules from github as part of the testing process. [16:01:01] Wondering if we should debianize them, or host them on gerrit, or just use a tarball, or... [16:01:10] to do what? [16:01:13] I lost you [16:02:07] andrewbogott: I must head back home, we can follow up by mail / gerrit review whatever :) [16:02:12] hashar: ok! [16:02:15] i might connect later tonight (europe time) [16:02:27] if my daughter agrees to get to bed early on hehe [16:02:39] paravoid, this is for puppet unit tests. There's an existing system that works pretty well... [16:02:43] *wave* [16:02:59] It sets up a virtual environment during the tests, which pulls things down from github. [16:03:03] what is? [16:03:10] rspec [16:03:35] can you start from the beginning? [16:03:44] sorry, I'm having trouble to follow [16:04:35] ok... [16:04:51] So… I want jenkins to run puppet unit tests. [16:04:54] right [16:05:01] and use rspec for this [16:05:04] yep. [16:05:07] okay [16:05:27] Right now if you run a unit test locally (via $rake spec) it starts by setting up a venv for the tests to run in [16:05:55]