[00:16:17] Aaah! [00:16:17] Your php dies during malloc [00:16:17] up the memory limit in php cli config? [00:16:17] Ryan_Lane: -1 [00:16:17] :P [00:16:17] heh [00:16:17] I think my process is just a bit too memory hungry :/ [00:16:17] * Coren wonders why the system doesn't go to swap though. Some peculiarity of the VM? [00:16:17] addshore: Yeah, I was about to ask wth you could be doing that had that heavy a footprint. :-) [00:16:17] preprocessing dump files :/ [00:16:17] addshore: In memory? [00:16:17] this was my first plan :P [00:16:17] and it has failed ;p [00:16:17] addshore: You may have to... err... revise your algorithm. :-) [00:16:17] yep :P [00:16:17] I think the easiest way may just be to parse the dumps to sql and then dump them in a DB [00:16:18] Ryan_Lane: You're going to be full of joy at the proxy config I got going for the tools project. I managed to cleanly isolate the tools /and/ sanitize away PII. :-) [00:16:18] overwrite the db with each dump [00:16:18] Coren: cool >) [00:16:18] err [00:16:18] :) [00:16:18] this would be allot easier with DB replication ;p *wink win nudge nudge* [00:16:18] maybe I should go and hunt for a pre made dump parser rather than trying to write my own :/ [00:16:18] Also PHP is not renowned for its judicious memory management. :-) [00:16:18] I know :P [00:16:18] * Jasper_Deng wonders why PHP was selected for MediaWiki in the first place.... [00:16:18] Ryan_Lane: *cough* *cough* https://gerrit.wikimedia.org/r/#/c/51312/ *cough* [00:16:18] Coren: you should get that cough looked at [00:16:18] Jasper_Deng: It's reasonable for what it was doing then, it has a good base of people who know it, and it's managable for most things. [00:16:18] Jasper_Deng: It could have been worse. It might have been implemented with Java servlets. :-) [00:16:19] Coren: hm [00:16:19] I rarely use virtual resources [00:16:19] now I need to look this up to properly review :( [00:16:19] Ryan_Lane: Oh? That's pretty much an ideal use case. [00:16:19] I'm not saying it's a problem [00:16:19] Ryan_Lane: Heh. Don't worry about a rush, just as long as it doesn't fall of your todo. :-) [00:16:19] * addshore thinks http://www.mediawiki.org/wiki/Manual:MWDumper may be his saviour [00:16:19] so, how is this conditionally included? [00:16:19] it's only realized if ssh_banner is set? [00:16:19] Ryan_Lane: You include the ssh::bastion class. This will cause ssh to realize the file resource. [00:16:19] * Ryan_Lane nods [00:16:20] Ryan_Lane: The advantages of doing it this way is (a) ssh::bastion might include more "bastionny" stuff eventually, and (b) other classes may want to define the virt resource if they need a banner. [00:16:20] Though of course you can only have one of those. I could have gone with the file-bits approach to construct a sshd_banner from a concat, but that seemed like heavy overkill to me. :-) [00:16:20] merged all the way through [00:16:20] yeah, this is a perfectly appropriate use of this [00:16:20] kk. FYI: the banners will stay everywhere they are, but puppet will only replace them (or add them for new instances) if the ssh::bastion instance is there. I'd have posted a change to put in in the openstack defaults, but I don't know how. :-) [00:16:21] meh, just remove the banner [00:16:21] there is no standard one [00:16:21] Heh. [00:16:21] * Coren might even have the grid working tonight. [00:16:21] that would be amazing xD [00:16:22] Ryan_Lane: Feb 28 23:42:20 tools-exec-01 nslcd[1082]: [7cfb34] error writing to client: Broken pipe [00:16:22] Something going on with LDAP? [00:16:24] Ryan_Lane: Gluster goes boom. [00:16:26] Coren: eh? [00:16:26] Coren: what specifically is breaking? [00:16:26] Ryan_Lane: No more gluster; nothing it the logs, every access gets stuck waiting on I/O [00:16:26] on which instance, on which project? [00:16:26] Ah. All instances of tools. [00:16:26] Includes /public/keys [00:16:27] Ah, except on -login which I had just recently logged in. [00:16:27] public keys isn't working? [00:16:27] Hm, no, that seems to have been a symptom of the homes being broken. [00:16:27] can you give me some instance names? [00:16:27] bots-webproxy [00:16:27] tools-webproxy* [00:16:27] tools-master [00:16:27] tools-exec-01 [00:16:27] trying to login to labs: [00:16:27] tools-webserver-01 [00:16:27] Login error [00:16:27] Labs uses cookies to log in users. You have cookies disabled. Please enable them and try again. [00:16:27] ? [00:16:27] Wikinaut: you need to use wikitech.wikimedia.org [00:16:27] argh [00:16:27] I wonder why that isn't redirecting. [00:16:27] redirect [00:16:27] ! [00:16:28] ===> http://www.w3.org/Provider/Style/URI.html <=== [00:16:28] There are multiple keys, refine your input: !log, $realm, $site, *, :), access, account, account-questions, accountreq, addresses, addshore, afk, alert, amend, ask, b, bang, bastion, beta, blehlogging, blueprint-dns, bot, botrestart, bots, botsdocs, broken, bug, bz, cmds, console, cookies, credentials, cs, damianz, damianz's-reset, db, del, demon, deployment-beta-docs-1, deployment-prep, docs, documentation, domain, epad, etherpad, extension, -f, forwarding, gerrit, gerritsearch, gerrit-wm, ghsh, git, git-branches, git-puppet, gitweb, google, group, hashar, help, hexmode, home, htmllogs, hyperon, icinga, info, initial-login, instance, instance-json, instancelist, instanceproject, keys, labs, labsconf, labsconsole, labsconsole.wiki, labs-home-wm, labs-morebots, labs-nagios-wm, labs-project, labswiki, leslie's-reset, link, linux, load, load-all, logs, mac, magic, mail, manage-projects, meh, mobile-cache, monitor, morebots, msys, msys-git, nagios.wmflabs.org, nagios-fix, newgrp, new-labsuser, new-ldapuser, nova-resource, op_on_duty, openstack-manager, origin/test, os-change, osm-bug, pageant, password, pastebin, pathconflict, petan, ping, pl, pong, port-forwarding, project-access, project-discuss, projects, puppet, puppetmaster::self, puppetmasterself, puppet-variables, putty, pxe, python, q1, queue, quilt, report, requests, resource, revision, rights, rt, Ryan, ryanland, sal, SAL, say, search, security, security-groups, sexytime, single-node-mediawiki, socks-proxy, ssh, sshkey, start, stucked, sudo, sudo-policies, sudo-policy, svn, terminology, test, Thehelpfulone, tunnel, unicorn, whatIwant, whitespace, wiki, wikitech, wikiversity-sandbox, windows, wl, wm-bot, [00:16:28] We just reorganized our website to make it better. [00:16:28] Wikinaut: yes, obviously. [00:16:28] Do you really feel that the old URIs cannot be kept running? If so, you chose them very badly. Think of your new ones so that you will be able to keep then running after the next redesign. [00:16:28] * Ryan_Lane sighs [00:16:36] (It's not my day, today. But there's still the night. (C) Wikinaut) [00:16:37] Coren: I can't even log in directly as root [00:16:37] Coren: are you logged into these systems? [00:16:37] Ryan_Lane: I have _one_ working (-login) but I dare not log off. :-) [00:16:37] that one works fine for me [00:16:37] you sure it's gluster? [00:16:37] Ryan_Lane: Try a ls of /data/project [00:16:37] what changes were made? [00:16:37] or a df for that matter. [00:16:37] that wouldn't cause a hang of login [00:16:37] Ryan_Lane: No, but the homes would [00:16:37] ah [00:16:37] let me check something [00:16:38] hm [00:16:38] it should be shared properly [00:16:38] public/keys works properly [00:16:38] homedirs should as well [00:16:38] data/project shouldn't cause hangs [00:16:38] Everything was fine until ~20 minutes ago [00:16:38] Maybe 30 by now [00:16:38] * Ryan_Lane nods [00:16:38] I'll check the servers [00:16:38] * addshore thinks his mysql permissions are a wee bit messed up on bots.mysql-3 on the table addshore_dump, would be great if someone could poke my permissions in the right direction again :/ [00:16:38] Wait, public/keys works on -login, like homedirs, but we don't know that it's working on the other instances. [00:16:38] And root wouldn't care about homedirs, only public/keys right? [00:16:38] if public/keys is working anywhere, it's working everywhere [00:16:38] hm. gluster volume seems to be non-responsive [00:16:38] the command, that is [00:16:38] can't go a week without dealing with gluster, it seems [00:16:39] * Coren starts eyeing NFS with longing. [00:16:39] I want to switch to the netapp pretty badly [00:16:39] why don't we have an NFS export per project ? [00:16:39] instead of fgluster [00:16:39] and beside NFS being evil? [00:16:39] :-D [00:16:39] hashar: hosted on what? [00:16:39] glusterfuck? [00:16:40] on the Gluster server? [00:16:40] a single point of failure NFS server will fuck us equally as hard at some point [00:16:40] that won't help us [00:16:40] yeah probably [00:16:40] though less likely than the crazy Gluster issues we are having [00:16:40] Ryan_Lane: Could just export block devices to the projects and they deal with per-project or whatever else they need? At least any failure then becomes project-local. [00:16:40] then we'll have a shit-ton of nfs servers [00:16:40] and we'll deal with entire projects being broken because their nfs is down [00:16:40] and people will use fstab [00:16:40] and we'll spend all day fixing instances rather than a centralized solution [00:16:41] Hm. Four quarters for a dollar; you'd trade one big problem for lots of little ones. I see your point, but I guess the question is how confident are you that you can beat gluster into shape? [00:16:41] ... if you did something, that worked. [00:16:42] I would rather have on project not having nfs instead of the full labs being awfully slow :-] [00:17:06] I havent seem gluster slowing things down in quite a while [00:17:15] hashar: part of the slowness is due to the network driver we use [00:17:21] we'll be solving that next week or so [00:17:26] ahh good to know :-] [00:18:05] Ryan_Lane: New data point: /data/project just unwedged on -login [00:18:11] yep [00:18:19] I just restarted glusterd service on all of them [00:19:09] How did you manage that without logging in? :-) [00:19:43] I did this on labstore1-4 [00:19:47] Oh, on the gluster stores. [00:40:54] __db.001: Applesoft BASIC program data [00:40:54] I'm thinking... no. :-) [01:09:58] Question for any bots people: Which instance do I do? O.O https://wikitech.wikimedia.org/wiki/Nova_Resource:Bots#Instances_for_this_project [01:11:08] pick one [01:12:04] Seriously? [01:12:48] well [01:12:50] dont use an apache [01:12:52] or an sql [01:12:59] or something specific to a person [01:13:05] like analytics or salebot [01:13:06] but yeah [01:13:33] * Riley just goes with bots-bnr1 [01:14:29] oh goodie [01:14:36] that'll teach addshore manners. [01:15:50] Hahah [01:17:00] bots boner? [01:22:11] I can haz gridz! [01:38:44] Coren: you has gridz? :P [01:39:03] legoktm: HAHA! [01:39:10] :D [01:39:40] Riley: whatcha running on there? :p [01:40:01] addshore: IRC bots and my sandbox bot [01:40:09] addshore: I haz a gridz! [01:40:33] can I has gridz? ;p [01:40:43] shame it cant have sql yet :/ [01:41:18] legoktm: what script were you talking about earlier to scan dumps? :P [01:41:28] * Riley waits like an hour for pywikipedia to transfer over to labs [01:41:29] give me like an hour? [01:41:34] its xmlreader.py [01:41:37] ill set it up for you [01:41:43] I had one but put little or no memory managment on it so I just chewed through 8GB in like 2 mins ;p [01:41:50] Riley: you dont need to copy it there [01:41:51] lolwut [01:42:01] addshore: no? [01:42:09] /data/project/pywikipedia [01:42:13] bbl [01:43:33] addshore: If you don't mind living on the bleeding edge, sure. [01:43:43] Coren: I love the bleeding edge ;p [01:44:15] What's your labs username? [01:44:23] addshore [= [01:44:24] Well, wikitech now. :-) [01:44:45] addshore: You can haz gridz. [01:44:47] also in regards to having sql with the gridz :P Could you not just setup a single sql instance? :O [01:44:51] addshore: tools-login [01:45:36] :D [01:47:28] addshore: Do you need a tool directory and stuff set up? That requires manual handling atm. [01:47:43] (Needed if you want to have a web interface) [01:47:55] wont need a web interface :) [01:48:20] Also needed for continuous jobs. [01:48:35] mhhhm, go on then :P [01:48:48] please to give me name of tool [01:48:54] addbot :P [01:53:42] addshore: project dir is in /data/project/addbot [01:53:57] cheers :) [01:55:11] addshore: only the tool can actually request continuous runs. You can sudo to it to do stuff. [01:55:27] Also http://tools.wmflabs.org/addbot/ [01:55:36] [= [01:55:37] (That's for free) :-) [01:56:03] You'll probably need to log off and back on to be in the local-addbot group [01:56:10] (the username for the tool is local-addbot) [01:58:04] okay :) [01:58:33] addshore: hint: sudo -iu local-addbot [02:02:50] Ooh [02:02:53] I want gridz! [02:03:01] Coren: plz [02:03:13] Heh. [02:03:25] wikitech username? [02:03:33] legoktm [02:03:59] Beware: this is very barebones still. There's a webserver for tools, a compute grid, and not much else. :-) [02:04:31] Sure. [02:04:42] legoktm: Read all the above speech to addshore, apply to yourself, then answer the same questions for me. :-) [02:05:04] * Coren copypastas said speech somewhere [02:05:43] Yes I would like a web interface. [02:05:55] If I make my tool name "legobot' can I still ssh as legoktm@blah? [02:07:08] legoktm: Yes, you sudo to the tool once on -login at need [02:07:16] legobot then? [02:07:27] Sure [02:07:50] * Coren makes a script to automate that. :-) [02:11:12] Ah, poop, puppet is fighting with me. [02:11:14] * addshore thinks Coren should add a mysql host ;p [02:14:40] All done but the sudoers [02:14:44] Hang thight [02:14:48] tight* [02:14:55] * legoktm hangs on for his life [02:15:05] well legobot does. [02:31:36] !Ryan_Lane [02:32:05] log bot is dead? [02:32:25] heh [02:32:33] any reason for a ping? :) [02:32:35] No, was about to poke you for a quick and simple puppet revie. It's just about to go ping on -operations. :-) [02:33:02] There it goes. :-) [02:33:38] Coren: please use modules [02:33:48] Even for one-offs? [02:33:52] yes [02:33:56] always modules [02:34:06] no more spaghetti code manifests [02:34:14] Oh. I shouldn't have looked at existing practice, huh? :-P [02:34:21] Will amend in minutes. [02:34:27] why are we using system sudo, rather than ldap? [02:34:54] Ryan_Lane: Because the data is locally generated and ldap sudo doesn't allow %group ALL=(user), as far as I can tell. [02:35:45] I'm confused by what you mean [02:35:58] The enties I need are: [02:36:14] %argoup ALL=(auser) NOPASSWD: ALL [02:36:19] yeah [02:36:21] that can go in ldap [02:36:25] Oh! [02:36:38] Hm. Then I need write access to ldap, don't I? :-) [02:37:18] (and if it goes in ldap then it's %agroup ahost=(auser) instead) :-) [02:37:27] when we add the interface to manage tools, it can add the sudo policy at the same time [02:37:59] Hmmm. And in the meantime, then, what do I do? Because atm puppet crushes any changes to sudoers or sudoers.d [02:38:26] So I can't do it locally. [02:39:19] do it via ldap [02:39:25] ah. crap [02:39:30] it lists the groups specifically [02:39:32] hm [02:39:54] Coren: puppet doesn't wipe out changes in sudoers.d [02:40:00] we don't recurse [02:40:08] Yes it does. It's a managed dir. It purges any addition. [02:40:11] temporarily you can do it that way [02:40:48] [[citation needed]] [02:41:14] * Coren is hunting for it. [02:44:01] dafu? I can't find it now, but that file was rm'ed under me at least twice in the past two hours. [02:44:15] * Coren is confused. [02:44:31] Allright, chalk it up to... Because ALIENS! [02:44:34] hahaha [02:44:52] it shouldn't [02:44:54] * Coren just ran a puppetd -tv just to be sure [02:46:44] legoktm: So, it works as advertized after all. :-) [02:46:54] Awesome! [02:46:58] Is there documentation somewhere? [02:47:06] Or do I just go crazy? :P [02:47:11] http://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Help [02:47:20] :-) [02:47:41] So, no. But I'm on-channel, just ping me at need. Documentation is... ongoing. :-) [02:48:12] legoktm: What probably interests you is /data/project/legobot [02:48:17] Ok [02:48:20] legoktm: there's a public_html in there. [02:48:26] So whats the basic workflow? [02:48:37] Do I just stick my tools in that directory? [02:48:45] I probably need a cgi-bin [02:48:52] legoktm: There's one too. :-) [02:48:58] :) [02:49:15] legoktm: Stuff in there is run by the user owning it, even from the webserver [02:49:44] the webserver is a valid submit host, so you can qsub things from your CGIs [02:49:55] ooh [02:50:03] and the syntax for job submission is the same? [02:50:34] Basically, though I expect the available queues are mostly different but that should be transparent to you. [02:51:02] You can also qstat to xml if you want to do fancy things like show the status of jobs from the web interface. [02:51:48] Your tool lives under http://tools.wmflabs.org/legobot/ [02:52:54] Remember that you should run your jobs as the tool user, and the cgis and php should be owned by it as well. [02:53:02] You can run one-off jobs as yourself if you want, though. [02:53:57] ping me for missing dependencies, I don't yet have most things installed. [02:54:04] Coren: Could you add me (scfc/tool wikilint) as well to the project? [02:59:20] scfc_de: {{done}} [03:01:20] Thanks! [03:01:41] Ah ok [03:01:43] thanks [03:11:38] Coren: I'd need libhtml-parser-perl libwww-perl liburi-perl libdbd-sqlite3-perl on -login and -webserver-01, and additionally libtool autoconf sqlite3 on -login. (And if apt-file isn't installed on -login, would be nice to install it there as well to look up packages.) [03:12:19] * addshore reminds legoktm about his dumps ;p [03:12:43] i just fought off a bunch of chinese spambots, finished CUing them and am exhausted [03:12:50] in a few hours [03:13:18] :P [03:14:05] I never realized how complicated CUing is [03:14:28] scfc_de: Kk. Gimme a minute [03:15:31] No problem. The webserver doesn't serve /data/project/* yet, does it? [03:21:00] scfc_de: Yes it does; yours would be at http://tools.wmflabs.org/wikilint/ [03:25:16] scfc_de: I'm presuming you want most (all) of that on the exec host as well. :-) [03:25:59] exec = SGE? Not necessarily, the tool is just a CGI. [03:26:20] scfc_de: Is it heavyweight? [03:26:32] No, I'm just an autotools fan :-). [03:26:51] scfc_de: Ah, ok. Cuz you can qsub stuff from the CGI for heavy duty stuff. :-) [03:27:02] I've seen your ads :-). [03:27:25] (I'll look into that for other things.) [03:28:01] hint: "qsub -sync y" is a useful idiom when all you need is the extra oomph [03:28:53] scfc_de: All your bits seem to be in place [03:29:33] Ah, so that's a bit like "ssh $SOMEWHERECOZY"? [03:30:07] scfc_de: Pretty much. [03:30:43] Also neat: qmake :-) [03:31:27] Hm. Not installed atm though. [03:32:31] Well, if I ever were to compile SGE ... :-) [03:33:04] -login is pretty fast, BTW. The DB conversion that's part of my Makefile went through in seconds, while on Webtools it took several minutes. [03:33:18] (Even though the instances look the same.) [03:35:00] Ooops. "make *-n* install" ... Let's time it again. [03:36:07] (Okay, apparently not super fast when it actually does what it's supposed to do :-).) [03:36:12] Heh. [03:36:28] It's a small instance; the intent is that any significant work should be farmed out to the cluster. [03:36:54] I'll probably add a -dev instance for compiles and stuff to leave -login snappy for interactive use. [03:39:24] Although, tbh, I don't think "snappy" is a realistic objective with gluster. [03:39:33] Don't know if it's worth the trouble (and users will be able to differentiate between "interactive compiles" and "interactive other uses"). [03:40:47] (Especially if SGE/OGS can be used easily.) [03:44:55] scfc_de: Ah, a caveat: any cgi or php you run will use the uid of the file it's in. [03:45:10] scfc_de: That usually makes things /simpler/, but you need to be aware. :-) [03:47:43] Coren: Don't you use the standard config? I believe in this all files beneath ~$USER/public_html are either served as the user's account (if various conditions are fulfilled) or not at all. [03:48:16] Coren: (Though not a problem, of course.) [03:49:16] scfc_de: In practice that shouldn't be an issue; the $USER owns the tree and so has control over ownership of the files within -- but there are security concerns about trusting an entire tree to a set of credentials rather than the specific object. [03:49:49] scfc_de: (I.e.: with the best practice of keeping all your tool files owned by the tools, there is no difference) [03:51:42] Yep, but AFAIR chown is effectively limited to root, so you can't clean up after the fact, but have to plan beforehand. [03:52:23] scfc_de: Well, there is always the make-copy-remove-bad-one idiom [03:53:01] cp broken broken~;mv broken~ broken [03:53:37] And, no, I believe mod_suexec makes a point of not trusting the entire tree, but looks at each file and if it doesn't fit the criteria, it's not executed as either the owner of the file or the owner of the tree, so it's pretty hard to shoot yourself in the foot. [03:54:09] The tool tree is sgid to the tool group, so the tool maintainers always retain control. [03:56:38] As long as it is possible to execute scripts as the tool user, I can cope with the rest :-). [03:57:46] Ah, but I'm not using mod_suexec. I'm using suphp which has some desirable properties for my setup. (faster, and also better handling of groups) [03:58:57] Although I admitedly configured it a bit liberally; flexibility always means it's easier to shoot *yourself* in the foot. :-) [04:00:49] Does it handle CGIs as well? :-) [04:00:56] (Perl CGIs, that is.) [04:00:57] scfc_de: Aye. [04:01:18] Though, tbh, I didn't actually /test/ that. :-) [04:01:33] Heh. [04:01:42] It should. If it doesn't, I'll fix it. [04:02:34] Oh, btw, make sure none of your stuff relies on living on any specific webserver; they may be moved around through webproxy as load demands. [04:02:54] (all of them will be identical, and see the same filesystem, so that should have no effect on you) [04:03:46] So, in short: Just like on Toolserver :-). [04:04:09] Neither River nor Daniel were fools. :-) [04:04:42] Some googling suggests that your assumption about suphp + Perl is true ... [04:05:27] There is a plausible difference, though: your scripts will not see the actual IPs of the users. Not sure if that was the case on the TS (I only ran bots there) [04:06:02] Probably; but I never used that. [04:07:25] One good thing that's going to be deployed soon: Wikimedia as openid server. [04:07:40] (soon as in "days" most likely) [04:10:03] Yep, my estimate at https://bugzilla.wikimedia.org/show_bug.cgi?id=13631#c17 was only off by three months :-). [11:52:23] !log bots added Hercule and Riley, trusted users [11:52:26] Logged the message, Master [11:52:34] Thanks [11:53:56] Riley: Actually you were added by Vacation9. [11:54:21] But he forgot to reply on talk page. [11:54:32] * Riley though there was a difference between being approved and being a "trusted user" [11:55:44] No differences, I think. That's just a reason in log and wouldn't affect other things. [13:39:22] * addshore wonders if he can modify somethinf or the gridz :D [14:30:32] Coren that system on tool labs you are working is going to be "production" or testing or both [14:31:01] petan: It's the future production system. [14:31:02] original proposal of bots project was consisting of two isolated areas, so that people can develop their bots on one and when ready, they update the "production" with latest version [14:31:24] petan: But it's easily replicated. [14:31:36] perhaps we could convert the current bots project structure to same as what you are making and use it for testing purposes [14:31:46] once it's usable of course [14:32:15] so that's it's less pain to move bots from current bots into your new project in future [14:32:17] petan: That sounds like a plausible scenario; but I'd make a different project rather than repurpose a current one as long as someone uses it. [14:32:32] addshore: Whatcha need? [14:32:58] need to make my scripts not use a DB ;p [14:33:03] petan: That said, there are already a few craz^H^H^H^H courageous volunteers working the new infrastructure pattern. :-) [14:33:26] link me to proposal [14:34:18] !tl is http://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Design [14:34:18] Key was added [14:34:31] !toollabs alias tl [14:34:31] Created new alias for this key [14:34:35] This you mean http://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Design [14:34:39] yes [14:34:40] ... yeah. [14:34:41] that's what I meant :) [14:35:16] @labs-project-instances tool-labs [14:35:16] I don't know this project, sorry, try browsing the list by hand, but I can guarantee there is no such project matching this name unless it has been created less than 34 seconds ago [14:36:02] * addshore needs to make a script to join all RC irc feeds :/ [14:36:06] @labs-project-instances webtools [14:36:06] Following instances are in this project: webtools-odie, node, webtools-login, webtools-apache-1, webtools-rr, [14:36:16] Coren is that tool labs project? [14:36:20] webtools? [14:36:27] addshore: I'm going to make a not-the-replica-DB DB anyways; there are clearly use cases where it would be counterproductive to hold stuff on the replication db [14:36:37] @labs-project-instances tools [14:36:37] Following instances are in this project: tools-login, tools-puppet-test, tools-webproxy, tools-exec-01, tools-webserver-01, tools-master, [14:36:45] awesome Coren :) [14:36:57] Coren that's where the bots are going to be? [14:37:17] petan: Eventually, yes. Right now, it's barebones functionnal but not ready for primetime. [14:37:30] ok can you insert me to that project? [14:37:37] petan: Sure. [14:37:43] Petrb [14:38:45] Gimme a minute and I'm all yours. [14:56:03] petan: Back. [14:56:21] petan: What's your labsconsole username? [14:56:26] Petrb [14:57:45] Please to read the pseudo-doc at http://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Help [14:57:56] ok [14:58:21] If you want a tool user (you almost certainly do) do tell me. :-) [14:58:50] ok that's very pseudo [14:59:13] yes if you think I do then I do :D [14:59:48] It's not so much "docs" as "raw data I keep around for when I write the doc" :-) [15:01:18] petan: Tool name? [15:01:42] I have no tool to run there yet, I just wanted to help out and check out how this new system works [15:02:13]