[00:00:20] [bz] (8ASSIGNED - created by: 2Maarten Dammers, priority: 4Normal - 6normal) [Bug 48851] Database inserts are slow - https://bugzilla.wikimedia.org/show_bug.cgi?id=48851 [00:05:26] hrmmm [00:48:49] anyone seen cobi recently there are reports of Cluebot not archiving [00:59:27] Apparently the continuous job on tools wasn't so continuous [00:59:39] * Damianz thinks it should be editing again now [01:00:14] Betacommand: ^ (Since I'm like 10min late) [01:00:32] Damianz: are you making sure that it always exits with an error? :) [01:01:20] Nope, it's a bit clungy so could exit cleanly in theory... probably need to tweak it, but not right now got build documentation to look at [01:02:55] right [01:51:03] Damianz: looks like its still not working right [01:52:44] What's up? It seems to be doing stuff in the logs, even if it is a little slow [01:55:17] Damianz: 1 edit in the last 30 minutes...... [01:55:46] Let me try something [01:56:54] thats not just being kinda slow, that's glacier slow [02:00:43] Hmm tools-login seems to have broken, wonderful [02:02:16] Coren: *Jab* [02:02:22] tools-login has a load of like 70 [02:02:32] The NFS server is currently overloaded. [02:02:36] :( [02:02:54] From what I can tell, it's going back down now; the instances should catch up shortly. [02:03:11] Vim just gave me my terminal back after quiting 2min ago heh [02:03:35] (Too many damn cron jobs on -login makes it pile up horribly at the least provocation) [02:03:40] Not breaking my bot though - it's doing the same on the other instance... think it's just behind hmm [02:04:08] Coren: Make a random cron job to sed crontabs for on the hour to a random number past the hour... bet less than 10 people complain [02:04:30] It shouldn't break anything, just slow things down. Filesystem was molassey for a while, but other than that nothing gets impacted. [02:04:59] Makes me sad I can't screen from a service account [02:05:08] The problem isn't a bunch of crontabs at the same time every hour, it's too many people running things every minute or every other minute, etc. [02:05:25] Damianz: Just screen from your own account before you become the service account. [02:05:33] I had a rule at my last job - if you made a min crontab, it got deleted lol [02:05:35] Same end result. [02:05:52] Coren: Yeah - but I was already in the directory I needed to be in... so I had to type an extra line [02:05:58] Yeah, I'm going to start cracking down on people mistreating cron. [02:06:02] * Damianz adds 'RSI inducing' to tools features [02:08:43] Damianz: Please to not run cluebot on -login! [02:08:59] Coren: Testing something, unless you have a better host for that [02:09:05] -dev! :-) [02:09:12] there is dev? [02:09:14] * Damianz goes there [02:09:19] Danke. :-) [02:09:50] * Damianz stabs screen for dropping his forwarded key [02:11:16] screen doesn't hold keys! That'd be horribly insecure. [02:11:30] It would be nice for the lazy though [02:11:37] legoktm: Why are you running stuff on -login? [02:11:51] legoktm: /data/project/legobot//dispatchstats.py [02:12:34] Oh, ffs. I see at least three heavy php and python jobs in cron. I need to start editing crontabs. [02:13:03] Coren: Oh. [02:13:06] Sorry [02:13:06] echo "no"; exit 1; wq! chmod 00? [02:13:25] I totally forgot about that [02:15:00] Coren: commented out [02:15:15] tsk, tsk. :-) Send it off to the grid. :-) [02:15:46] Well I should figure out what those scripts actually do.... [02:16:01] Coren: Could you start calling it the cloud, so I can make fun of you? [02:16:02] :P [02:16:20] Damianz: Nope. [02:17:21] * Coren kills the worst offenders. [05:58:48] New patchset: Ori.livneh; "Correct typo in passwords::mysql::eventlogging" [labs/private] (master) - https://gerrit.wikimedia.org/r/74113 [08:22:18] !log deployment-prep beta jenkins jobs statuses are now listed on the CI main page at https://integration.wikimedia.org [08:22:21] Logged the message, Master [08:22:48] hashar: hey, I have jenkins newbie questions [08:23:03] paravoid: I will be more than happy to help :-] [08:23:46] so we're soon going to have a repo for DNS [08:23:52] where people will submit zone changes [08:24:10] so I want jenkins to check those and set V+1/- [08:24:24] I'll prepare the black magic to do so [08:24:25] but [08:24:49] what's the interface going to be? [08:24:53] jenkins spawning a binary? [08:25:12] is it going to clone the gerrit changeset somewhere or is my script going to do that? [08:25:22] iirc named as a way to lint a set of config [08:25:24] oh heh, just realized it's the wrong channel [08:25:39] we can follow up in -ops or -dev if you want [08:25:45] nah, it's fine [08:25:57] so you were saying [08:26:20] so when you send a patchset in Gerrit, it sends a JSON notification over ssh to Zuul [08:26:39] Zuul receive the JSON notification, fetch the patchset from Gerrit and merge it with the tip of the repository branch [08:27:21] Zuul (if properly configured) then trigger a Jenkins job passing the git project name, the merge commit (your patchset merged on tip of branch) and various informations [08:27:36] Jenkins start the jobs with the parameters which are being used by a git Jenkins plugin [08:27:47] the plugin would then clone the repository and checkout your patchset [08:28:12] from there we can add build steps such as "running a shell script" [08:28:38] which might be something like: named --lint $WORKSPACE/files/named/* [08:28:38] where would it clone it? [08:28:46] it is cloned on the Jenkins worker [08:29:09] we need to put it in a special directory structure for gdnsd to work [08:29:17] somewhere hidden like /srv/ssd/jenkins/workspaces//workspace , but that is exposed as the env variable WORKSPACE [08:30:02] what kind of tests do you want to achieve ? [08:30:17] I guess a basic step would be to validate whether the zone files are valid (aka linting) [08:30:25] yes [08:30:30] so, we're going to run gdnsd [08:30:45] a more complicated one would be to boot a gdnsd server and run a script that does DNS queries on it and assert results (aka integration test) [08:30:52] gdnsd has a "gdnsd checkconf" argument (which actually checks zones too), that would be the first thing to run [08:31:03] but [08:31:18] to run this, either of these two things need to happen [08:31:32] a) have zones at /etc/gdnsd/zones and config at /etc/gdnsd/config [08:31:56] b) have them under a random dir with a specific structure, e.g. /tmp/tmp.XXXXX/etc/{zones,config} [08:32:08] and then run gdnsd with a -d that /tmp dir, which is the "chroot" mode [08:32:32] so my script can do all that [08:32:56] set up a temp dir, copy from the workspace, prepare the zones, run gdnsd checkconf and then cleanup the dir [08:33:19] you could run gdnsd checkconf directly in the workspace I guess [08:33:29] gdnsd --checkconf $WORKSPACE/path/to/config/files [08:33:53] no [08:33:55] not possible [08:34:05] for multiple reasons :) [08:34:09] the pass are hardcoded ? [08:34:14] grr [08:34:19] the paths are hardcoded ? [08:34:22] a) if you give gdnsd a directory it needs to be under 'etc' and our git tree doesn't have that [08:34:41] so if you say gdnsd -d /tmp/foo checkconf, it'll look for the zones under /tmp/foo/etc/zones [08:34:52] and our git tree won't have etc [08:34:55] that's (a) [08:35:32] b) we'll use templates for zones, so the repo we need to run some other stuff to compile zones anyway :) [08:36:06] so you want to figure out a way to expand all the zone files from templates [08:36:07] ok, so, I'll prepare a script that takes a directory with a checked out tree as input and does all things necessary [08:36:14] oh I have that, that's easy [08:36:40] the expanded zone files would be written under $WORKSPACE/etc/zones [08:36:48] and then you can gdnsd -d $WORKSPACE [08:37:01] yeah, I can create an arbitrary structure under $WORKSPACE [08:37:44] and we can ask Jenkins to wipe all the files in the workspace before starting a build [08:37:57] this way you are sure to always run the tests starting with a clean start [08:38:07] oh so workspaces are permanent? [08:38:12] by default? [08:38:17] yup [08:38:30] the git plugin as an option to wipe them before fetching the code [08:38:37] and there is also a plugin that let one wipe it [08:38:57] for most repository, we do wipe the workspace entirely and start everything fresh (including doing the git clone again) [08:39:16] but since the workspace dir and the repositories are on the same SSD device, git creates hardlinks and seems to be very fast at cloning [08:39:36] I had to many issues earlier in keeping the workspace and simply run git clean -xqdf (remove everything un tracked) [08:39:43] that sometime left oddities in the workspace :/ [08:40:01] * hashar reads gdnsd man [08:41:58] don't worry about that :) [08:42:03] paravoid: yeah that should be easy [08:42:05] ok so my script can basically do [08:42:16] mkdir $WORKSPACE/chroot [08:42:43] do you need a chroot to run checkconf ? [08:42:44] mkdir $WORKSPACE/chroot/zones; authdns-gen-zones $WORKSPACE/templates $WORKSPACE/chroot/zones [08:43:00] no, but the alternative is using /etc/gdnsd :) [08:43:43] hehe [08:44:04] so yeah in the end it is pretty simple [08:44:13] the longest / hardest part is figuring out what commands to run [08:44:21] and make sure they will run fine under Jenkins constraints [08:44:37] (and getting ops to merge puppet change) [08:45:06] which repo are the zone files in ? is that ops/puppet ? [08:45:18] I noticed a git repo operations/dns/ [08:47:56] the chroot is easier and a bit more safe [08:47:56] if we also use a random chroot dir name we can run multiple tests at the same time too [08:47:56] not that we'll have so many updates [08:49:56] jenkins supports running the same job in parralel [08:50:03] there's an operations/dns? [08:50:06] it simply execute in different workspaces [08:50:07] I haven't pushed the repo yet [08:50:14] put that was my intended repo [08:50:22] something like workspace , workspace@2 , workspace@2 [08:51:34] ah it's empty [08:51:47] but it has two commits that I need to get rid of somehow [08:52:39] create an orphan branch [08:52:50] and cherry pick the changes you need on that orphan branch [08:52:57] or you can do a git rebase --interactive [08:52:59] which let you remove commits [08:53:10] you might want to try on a copy [08:53:38] 11:00 wohho. [08:53:41] oh I have a history already [08:53:57] I just don't think gerrit will allow me to override master completely [08:54:00] drop those two commits [08:54:10] I have a tree that I converted from SVN [08:54:11] :) [08:55:22] you can force push in gerrit if needed [08:55:46] I can? with git push -f ? [08:55:57] so operations/dns currently has two commits [08:56:01] one is an empty one [08:56:06] and the other is .gitreview [08:56:09] yes [08:56:12] master is pointing there [08:56:22] you can push your content and override them entirely [08:56:34] with something like: git push -f origin HEAD:master [08:56:47] you will need to grant yourself force push right in Gerrit interface [08:57:05] ah [08:57:15] I knew git push -f but last time I tried it Gerrit rejected me [08:57:22] but it was the right thing probably [08:57:26] and I can do that anytime? [08:57:27] that is disabled on all repos iirc [08:57:56] paravoid: https://gerrit.wikimedia.org/r/#/c/74122/ :-) [08:58:04] that is the configuration to let you force push [08:58:09] it is done on https://gerrit.wikimedia.org/r/#/admin/projects/operations/dns,access [08:59:13] merged [08:59:18] oh hah [08:59:21] you rock hashar :) [08:59:27] my job :] [08:59:36] been playing with Gerrit for the last 18 months or so hehe [09:01:13] pushed [09:01:22] it's not the final one, I'll force push a few more times until we deploy [09:01:25] (svn is still read-write) [09:03:04] full history [09:03:22] all the way back to 2011 [09:05:15] paravoid: you can also push your current work under a temp branch [09:05:26] and we can setup a jenkins job to pointing to it [09:06:10] nah, the CI part can wait [09:06:16] paravoid: I have created a branch named "jenkins" :D [09:06:20] until we deploy [09:06:25] we have no checks now at all [09:06:34] well i am in vacation in 7 business days [09:06:52] so if you want CI before september, we need to have it done soon :] [09:07:10] for how long are you leaving? [09:07:21] all of Aug? [09:07:40] for 3 weeks [09:07:56] first week i will be barely reachable, second week I can handle the critical issues / catch up [09:08:01] third week out again [09:08:04] that is a french thing :-] [09:08:07] okay [09:08:11] yeah I know :) [09:08:40] anyway other people are able to assist such as Timo and marktraceur [09:08:47] and other random folks too [09:11:11] don't worry, I'll figure it out :) [09:17:18] mkdir -p "$WORKSPACE"/chroot/zones [09:17:19] authdns-gen-zones "$WORKSPACE"/templates "$WORKSPACE"/chroot/zones [09:17:20] gdnsd -d "$WORKSPACE" [09:17:29] that would need the gdnsd package installed on the jenkins slave though [09:17:42] yeah I'll create an authdns::ci class [09:17:48] it also needs authdns::scripts [09:20:27] that will need to be included on all the Jenkins slave [09:20:36] I don't think I have a proper role class to do so yet [09:21:13] so the jenkins template is at https://gerrit.wikimedia.org/r/74124 [09:21:15] that is some yaml [09:21:36] but you can skip that and just edit the job manually in the jenkins interface while logged in with your labs account https://integration.wikimedia.org/ci/job/operations-dns-lint/configure [09:21:52] scrolling at the bottom is a 'Execute shell' which is where you can put your stuff [09:25:49] and zuul triggers https://gerrit.wikimedia.org/r/74125 [10:52:32] paravoid: and I wrote a lame tutorial about what I did https://www.mediawiki.org/wiki/Continuous_integration/Tutorial/Adding_basic_checks :) [10:52:39] \o/ [10:59:36] hashar: how is zuul triggering this job? [11:03:02] matanya: it uses Jenkins REST api [11:03:11] ah, thanks [11:03:22] so basically some HTTP query like /job/somejobname/buildNow?param=value¶m2=something [11:03:33] then Jenkins notify back Zuul with the result [11:04:01] one day I will have to write a technical documentation explaining all the interactions [11:06:35] paravoid: of course the job fails terribly since operations/dns is empty and gdnsd is not installed :-] https://integration.wikimedia.org/ci/job/operations-dns-lint/2/console [11:06:54] I'll fix the script, no worries [11:07:02] (operations/dns isn't empty anymore though) [11:07:16] https://integration.wikimedia.org/ci/job/operations-dns-lint/ws/ :-) [11:07:19] that show the workspace [11:19:40] paravoid: looking at operations/dns all commits belong to root [11:19:45] was that the case in svn? [11:20:00] yes... [11:20:13] :( [11:20:17] yeah [11:20:36] at one point I commited something with my username [11:20:50] then noone else used --user or whatever the svn option is [11:21:03] so it ended up having a bunch of commits that had my name but weren't mine [11:21:14] so I actually rewrote those to root now [11:21:53] make sense [11:22:16] but, history with root is better than no history [11:22:32] I am really happy to have the DNS zone made public [11:22:41] that is going to let volunteers fix up entries :-] [11:24:22] yep [11:24:25] that's the plan [11:24:56] I remember using some dns checker [11:25:03] it was doing an AXFR and making sure the PTR entries were properly set [11:25:11] or report SOA errors / double CNAME etc [11:25:26] but maybe I wrote it, I can't remember [11:25:44] had it to run as a nagios check and report an issue for the NOC to fix them up :-] [11:28:34] http://support.microsoft.com/kb/321045 :-) [11:28:37] by microsoft [11:29:40] @notify Coren [11:29:40] This user is now online in #wikimedia-labs. I'll let you know when they show some activity (talk, etc.) [11:47:10] !paste [11:47:10] http://pastebin.com [11:47:13] !paste del [11:47:13] Unable to find the specified key in db [11:47:21] @search paste [11:47:21] Results (Found 1): pastebin, [11:47:24] !pastebin del [11:47:25] Successfully removed pastebin [11:47:34] !pastebin is http://tools.wmflabs.org/paste/ [11:47:34] Key was added [11:48:17] http://tools.wmflabs.org/paste/view/ac45194d \o [11:48:23] finally we have own pastebin :D [11:56:51] * Coren pokes Krinkle. [11:57:54] Coren: Hi, I was wondering about what the plans are to get other tables known at toolserver to Tool Labs (or WMF Labs in general). I know the production wiki contents are now replicated, but meta databases such as toolserver.namespaces and toolserver.wikis are a blocker for some of tools I was about to migrate. [11:58:41] https://wiki.toolserver.org/view/Toolserver_database [11:59:13] Krinkle: Well, it's on my list, but there's like 27 different things ahead of that. That said, if someone makes that data available it'd only take me minutes to make it globally available. [11:59:35] Coren: It needs to be generated periodically based on wmf-config [11:59:52] There's even a bz tracking that, iirc. [11:59:54] e.g. namespaces changes, wikis get added [12:00:03] Got a link for me? [12:01:42] https://bugzilla.wikimedia.org/show_bug.cgi?id=48626 [12:02:05] Part of my concern is that this needs to be maintainable. [12:03:23] It is manually maintained at toolserver, however I think it can be done automatically nowadays. All the data is "somewhere", just not in a database. [12:04:54] Right. "Manualy maintained" == "Not maintainable" :-) [12:04:58] However this is case where some data is better than no data. For maintainability of tools, fortunately many toolservers found out the hardway that this way you'll never need to update things like adding support a particular wiki, namespace or language. You can just use those tables are the source for the selectors in the UI. [12:05:16] At which point maintaining it in one place is still more maintainable than requiring people to do it manually [12:05:24] because at this point in time it will mean they won't do it [12:05:52] I mean, I'm not going to do all this for each tool separately. [12:06:14] Oh, I agree. [12:06:45] Hence, if the data exists, I will make it available. [12:07:07] Coren: Anyway, just saying, I've been asked to migrate tools before November (all wmf staff has, to give a good example). But I can't do that without this information. Even a potentially outdated copy of that toolserver has now would be good enough. Even if the data is missing 2 or 3 recently added wikis and some name spaces chnages, the majority is there. [12:07:14] I can do a dump for you right now. [12:07:19] it is public on the toolserver [12:07:46] Probably easier for you to do it, I don't now the mysqldump commands very well and I'd have to send it around etc. [12:07:52] *sigh* I'm not a fan of temporary hacks; they have the bad tendency of becoming permanent hacks. [12:08:17] But yeah, if it's a blocker I'll see what I can do when I find a bit today. [12:08:22] Yes indeed. But unless you can prioritise writing an automated script for generating this data into MySQL within a month or two.. [12:08:37] Let me know if you need anything. [12:09:46] did Toolserver ever have memcached? [12:10:07] Krinkle: ^ do you know? [12:12:01] YuviPanda: just checked, they don't have php5-memcached installed. They might have memcached itself running, but I doubt it. Too much potential for key conflicts. You'd have to run it yourself, which might be possible if you can run it from your /home/*/bin [12:12:11] Krinkle: ah, okay. Just checking [12:12:25] we've Redis, and memcached that we want to kill, so 'hard to port toolserver tools' is not an argument at all, then [12:12:38] I think I did that once actually. They do allow listening on ports (e.g. to run a ZNC irc bouncer) [12:12:59] Yeah, that's one less problem ) [12:13:45] indeed [12:24:32] @infobot-share-trust+ #wikimedia-labs-offtopic [12:24:32] You inserted channel #wikimedia-labs-offtopic to shared db [13:36:05] Cyberpower678: Oh, wow. https://meta.wikimedia.org/w/index.php?diff=5656451&oldid=5656420 shows a complete lack of knowledge about how things ever worked. [13:43:03] @jb bla [13:43:07] @unjb bla [14:07:31] that entire RFC just seems to be an invitation for someone to setup the tool in another instance and make it all public [14:07:48] meh [14:14:28] Coren: Re "most scripting language require around 300-350M of virtual memory to load completely" on the help page, I decided to do some experimenting. I submitted jobs that just did the equivalent of "php -r 'sleep(60);'" for various languages: the Perl version reported a peak VMem of 17.1M (and ran fine with h_vmem=20M), Python reported 28.7M (and ran fine with h_vmem=30M), PHP reported 257.1M (but failed with h_vmem=300M, it needed h_vmem=350M) [14:14:28] , and nodejs reported 640.0M (but failed with h_vmem=700M, it needed h_vmem=750M). [14:15:06] And for fun, I uploaded the (dynamically linked) lua binary from my system. It reported 13.7M, and ran fine with h_vmem=14M. [14:15:17] anomie: Yeay data! [14:16:13] All those numbers are with 1M = 1024*1024 bytes, BTW. [14:16:23] yes, M vs m [14:16:48] I keep forgetting that... idiosyncracy of sge. [14:17:21] Coren: did we ever push default from 256 to 512? [14:17:22] I don't think M vs m is any sort of real standard, is it? But gridengine uses that distinction. [14:17:47] BTW, reported vs needed is expected; sge only records usage at interval, whereas the startup code from linux-ld.so does release some stuff after initial setup so it peaks a bit higher. [14:17:48] Oh, I misread "sge" as "age". Nevermind [14:18:44] Nobody sane ever uses powers of ten to count memory. Nobody honest uses them to count disk space. :-) [14:19:49] And only someone insane would ever arrive at 1.44M when measuring 3.5" hd floppies (since it requires defining a meg as 1000*1024 bytes) :-) [14:20:39] I was *just about* to mention 1.44M floppies, after I verified that I was remembering correctly. [14:20:50] oh wow, I never knew that. [14:22:37] YuviPanda: Are you young enough that you never really had to deal with floppies? [14:22:54] anomie: I had to deal with them for 2-3 years, from about 11-14, I think [14:22:59] but didn't know of the 1024*1000 thing [14:23:31] Bought a rather expensive 256MB flash drive at 14 or 15, I think :) [14:23:49] I still have boxes at home [14:23:56] well, a box. it probably has 4-5. [14:24:09] anomie: waay too young for non 3.5" though :) [14:25:48] * anomie missed 8", but thanks to having a 10-year-old computer at age 10 has dealt with both 5.25" disks and a cassette tape recorder. [14:29:48] * Coren has had fun with 8" floppies. Lots of nostalgia there. [14:30:03] First of, they had over a *meg* of space. [14:30:24] (when 5" floppies were lucky to head for 200K) [14:30:36] YuviPanda ping [14:30:37] And the noise... still has me nostalgic. [14:30:42] petan: pong [14:30:46] YuviPanda: you want tools-redis? :o [14:30:50] Coren: I don't remember modem noise, ever :) [14:30:57] dialup modem noise that is [14:31:05] (You see, "head load" on 8" drives doesn't mean "start the motor", it means "load the head". Ka-klunk!) [14:31:59] And they had big seek stepper motors. I can still remember the sequence of clunks and crunches that meant FLEX was booting on my S09 (my first real computer) [14:32:03] petan: yes, if we have an instance that runs redis, what is the point of calling that tools-'mc'? [14:32:28] A rose, by any other name, smells just as sweet. [14:32:43] Coren: my memorable sounds with a computer early on were just playing with sound() and nosound() with sleep patterns, from dos.h [14:33:03] Coren: I should have you review code where all temperoary variables are named after characters from movies you never see [14:33:08] YuviPanda: there is no point just a reason [14:33:09] Ironholds does that, it's infuriating. [14:33:25] historical reason. [14:33:29] it was originally memcached, redis is just alien :P [14:33:41] That way lies my nostalgia: http://oldcomputers.net/swtpc-s09.html [14:34:05] *shrug*. I don't get the redis hate. [14:34:19] Back in 1981. :-) [14:34:35] ogod. That's over 32 years ago. [14:34:44] * YuviPanda calls Coren old man [14:37:35] * Coren realizes he got his first computer before most of his colleagues were born. [14:39:39] Coren: clearly, we need to hire Stallman [14:39:47] and make him a... community liason? :) [14:42:12] ... no. [14:43:20] I can think of worse ideas, but they all revolve along the lines of involving Kim Jong Un in diplomatic roles. :-) [14:44:05] hmm, Kim Jong Un as part of arbcom? [14:44:14] we *hire* him and then put him on arbcom [14:44:19] and create a new flag. [14:44:32] and pull a piratebay and announce we are moving our servers to NK [14:44:49] too much work. [14:55:04] [bz] (8NEW - created by: 2Chris McMahon, priority: 4Unprioritized - 6major) [Bug 50622] Special:NewPagesFeed intermittently fails on beta cluster; causes test failure - https://bugzilla.wikimedia.org/show_bug.cgi?id=50622 [14:56:38] [bz] (8REOPENED - created by: 2Chris McMahon, priority: 4Unprioritized - 6major) [Bug 50623] Entering AFTv5 feedback causes error - https://bugzilla.wikimedia.org/show_bug.cgi?id=50623 [15:00:57] I just did memcached in my bot a month ago, and now I have to change to redis? Sigh. [15:02:14] anomie: it is a rather very quick change, and you might find that other things might also be sped up by using redis [15:02:27] anomie: and remember to use a large-enough prefix to avoid clashes! :) [15:04:53] YuviPanda: Define "large enough". With memcached, I'm using "AnomieBOT:". [15:05:06] !tools-help [15:05:06] https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help [15:05:07] moment [15:05:20] anomie: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Security [15:05:27] anomie: 'openssl rand -base64 64' is my preference [15:06:04] YuviPanda: Also, my memcached interface code will automatically encrypt (most of) the values being stored ;) [15:06:14] anomie: doesn't prevent me from *overwriting* it :) [15:06:38] we've disabled all(hopefully!) ways of listing keys from Redis [15:06:41] but still [15:08:48] hi Coren [15:09:05] liangent: Hey there. [15:09:08] YuviPanda: BTW, please install libredis-perl for me. [15:09:20] anomie: ah, okay. patch coming. I thought I had.. [15:09:29] Coren: that bug? [15:09:32] see mail [15:09:50] YuviPanda: Looks like you have php and python already, but not perl. [15:09:59] Oh, yeah. Can you give me ~20 mins then I'm all yours. [15:10:01] anomie: okay, sending puppet patch now. give me 5 [15:10:06] ok [15:10:47] YuviPanda: No rush, I won't start coding for at least 6 hours, and I may not get to it until next week. [15:11:30] anomie: okay :) [15:14:40] Coren: two trivial patches in labs puppet for you to +2. [15:16:58] yurik: Which is the other? [15:17:16] Coren: https://gerrit.wikimedia.org/r/74161 [15:17:21] and autocomplete strikes again :) [15:18:20] Coren: ty [15:18:33] anomie: perl redis library should be installed on next puppet run, in ~30 mins I guess [15:21:47] YuviPanda: how complicated is it to migrate data from 1 redis to other one? [15:22:07] petan: rather simple. we can just copy the AOF files, point them and it should work [15:22:14] right [15:22:18] we should schedule a switch then [15:22:34] OR we could just start the new redis and tell all people to move their data and bots to it? [15:23:31]