[00:11:13] andrewbogott: wikitech-test (in the openstack project) is working for two regions [00:11:21] I need to commit the changes and push them to gerrit [00:11:31] cool! [00:11:31] I think there's some more stuff I need to fix [00:11:48] for instance, we need to fully qualify instance Nova_Resource page names [00:11:54] otherwise instance ids overlap [00:12:02] we may also have issues with DNS code? [00:12:09] though I'd think we shouldn't [00:12:23] ok. gotta run [00:53:55] hrm. the 404/500/403 pages on toollabs are kind of broken; they pull full content into the index template. [02:15:03] Did you know that you can disable these tips but doing [02:15:03] touch ~/.suppresstips [02:15:08] s/but/by/; [02:15:23] This isn't really worth the time and energy of going to bugzilla, so I'll just leave it here [02:15:35] * SigmaWP beckons Coren ^ [07:16:55] Coren: warning Due to an issue on Wikimedia Labs s7 databases server, these informations cannot been displayed. Please wait that the problem is fixed or request help at #wikimedia-labs. [07:38:20] !log tools restarting grrit-wm, for some reason it reconnected and lost its cloak [07:38:22] Logged the message, Master [07:39:21] !log tools grrrit-wm restart didn't really work. [07:39:23] Logged the message, Master [09:42:28] jeremyb: ping [10:42:33] zhuyifei1999_: ? [10:43:47] ok, good night! [10:43:55] in the future don't ask to ask! [10:44:00] !ask [10:44:00] Hi, how can we help you? Just ask your question. [10:44:04] jeremyb: could you please restart wm-bot? [[bugzilla:58968]] [10:50:46] @seen wm-bot2 [10:50:46] zhuyifei1999_: Last time I saw wm-bot2 they were joining the channel, they are still in the channel #wikipedia-en-helpers at 12/27/2013 10:50:45 AM (1s ago) [10:51:40] @seen wm-bot3 [10:51:40] zhuyifei1999_: Last time I saw wm-bot3 they were joining the channel, they are still in the channel ##Pratyya at 12/27/2013 10:50:45 AM (55s ago) [10:52:06] jeremyb: thanks! [10:52:32] nacht [12:19:03] Nemo_bis: hi, got you [12:19:21] I knew you are in at least one common channel ;) [12:28:29] heh [12:29:19] #wikimedia or #mediawiki would be better, but as you wish [12:31:53] gui.llom is probably afk for a while still, I think you can/should continue with that page as you manage and then we see how many tasks to count for it [13:54:56] andrewbogott_afk: Wave when you get in. [15:35:39] jorm: can you separate maintainers in tools.wmflabs.org/?tool=… by comma? [16:11:05] Coren, what's up? [16:11:27] andrewbogott: Got some time to discuss a few pending matter re the migration and the new setup in eqiad? [16:11:40] sure. [16:12:55] One of the things that would make things 100% better from the filesystem pov is if we used the opportunity to the the service group name unification Ryan was planning. How complicated do you expect it to create service groups slightly differently in eqiad while keeping the legacy system in pmtpa? [16:14:24] Is this just having service group names be unique across the region? Or something else? [16:14:24] I.e.: can the service group management behave differently depending on whether it's talking to one site or the other? [16:14:50] andrewbogott: Unique accross the region, named differently ($project.$group), having a different default group, and being grouped in the same OU rather than one-per-project. [16:15:11] hm [16:15:35] we're going to replicate ldap across both regions. So having it diverge in the back end seems hard. [16:15:36] It's not huge changes in LDAP or the wikitech code, but the tricky part would be to support both systems at once for a while. [16:15:56] Maybe harder than just changing it everywhere in the first place. [16:16:16] We can have both systems coexist in LDAP afaik; it's really just a difference on how new groups are created. [16:16:41] what about existing groups though? [16:16:58] Changing it everywhere will be disruptive in the projects though; lots of small changes all over the place. Easy to do while you migrate a project, no so much on a live one. [16:16:59] Ah, I see. Hm. [16:17:28] andrewbogott: We can keep them in the legacy style; when people migrate their projects they create new ones that'll use the new scheme (or do it for them automatically) [16:17:54] And when we shut down the pmtpa region, we just cleanse the LDAP. [16:18:38] I still don't quite follow what the eqiad vs. pmtpa factor is in this. Wouldn't we just be changing the behavior for new groups vs. old? [16:18:40] new groups in either dc? [16:19:38] Well, I suppose we could, but then you'd have to add code to support both schemes in both locations rather than just if(pmtpa project) old_stuff() else new_stuff(); [16:20:51] My primary point is "We probably want to fix the service group thing before we start creating stuff in eqiad". The rest is just trying to ease migration pains. [16:21:41] It would be a big win for me if I could have the new NFS server not support the current hacks. [16:22:00] Tweaking all this by hand during migration sounds like a real pain… but I guess it mostly only affects tools. [16:22:21] Anyway, I'm happy to work on it -- is there a bug anywhere describing the new vision? [16:22:24] Mostly. From what I've seen, service groups usage in other projects is limited to 2-3 per. [16:22:43] andrewbogott: Not yet, I wanted to see if you had insight. I'll create one now then. [16:23:21] thanks, that'll give me time to digest. [16:23:21] Were there other migration things you wanted to talk about? [16:26:03] andrewbogott: There was also an interesting question: will the way your're doing things with Mike and regions allow having instances bearing the same name in eqiad and pmtpa during the migration? [16:26:23] In theory it will. In practice, interesting things may happen :) [16:27:24] I might actually put something in the gui to explicitly prevent creation of duplicate instance names, though -- we don't want name collisions when migrating. [16:29:05] Migrating tools without being able to keep, say, tools-login.pmtpa.wmflabs and tools-login.eqiad.wmflabs would be a serious hinderance for tools. Not insurmountable, but serious pain. Perhaps allow some way to force it? [16:30:06] So in some cases you'll want duplicates rather than to just transfer an existing instance? [16:30:06] I'll keep that in mind [16:30:11] Hello All! [16:31:07] I need help of someone experienced in working with plain C/C++ python extensions ... anybody? :) [16:31:09] (forget the "plain") [16:31:47] andrewbogott: For tools, I will not migrate any instance. [16:31:51] DrTrigon: I have C++-fu, but my python is weak. [16:32:40] No problem - I think its more on the C++ side... I compiled everything witout (serious) issue, but now I get: "Wrong JPEG library version: library is 80, caller expects 62" [16:33:08] andrewbogott: It's going to be much easier on me /and/ the users to migrate projects between two different "tool labs" that it'd be to try to migrate tool labs itself. Also, it means that most people will be able to migrate without interruption. [16:33:08] google tells me its related ti ImageMagick [16:33:28] DrTrigon: Are you trying to link to ImageMagic /and/ libjpeg? [16:33:29] looks like... [16:34:49] That's always a pain, IM has its own libjpeg its bound to, so you need to use the exact same otherwise you'd end up mixing the system default with the one ImageMagic attempts to use implicitly. There's a workaround for that, although I don't recall the trickery needed off the cuff. Give me a minute to look it up? [16:35:24] Coren: If you can help - you can also have an hour ... [16:35:45] (said that a minute would be better... ;)) [16:37:12] Coren: makes sense. [16:37:52] Going to get some breakfast, back soon. [16:38:12] Enjoy it! :) [16:39:37] andrewbogott_afk: https://bugzilla.wikimedia.org/show_bug.cgi?id=58997 [16:42:36] DrTrigon: Where are you trying to build your extension? [16:42:56] tool-labs [16:43:16] (or what do you mean by "where"?) [16:43:16] tools-login, tools-dev [16:43:37] tools-login [16:45:37] Allright; the problem is ImageMagick was build with libjpeg62, but right now we have lighjpeg8 installed as default (which is the latest). I can install libjpeg62-dev, but you'll have to tweak your makefile(s) to use that for includes and libraries explicitly. [16:46:39] libjpeg* [16:46:58] Coren: ...so we do not have the option to use consistent libraries (same libjpeg on system than ImageMagick uses) ...? [16:47:59] Downgrading libjpeg would break other things that rely on a modern version. The issue is that Imagemagick uses an antique libjpeg. If you link against it, then you need to use that same antique yourself. [16:48:24] It's unarguably a bug in Imagemagick. [16:48:39] Coren: Ok I see - either get rid of ImageMagick or tweak my makefiles... [16:49:01] Right. [16:49:01] How would I have to tweak them? Just replace "libjpeg" by "libjpeg62" everywhere? [16:51:42] Coren: ^^^ [16:52:11] DrTrigon: No, you'll need to specify a -I and -L when building and linking; give me a litte bit more time while I figure out what exactly you need to do. [16:52:24] ...oooo sorry! ;) [16:52:42] DrTrigon: Where is your currently broken executable? [16:53:43] I have a python script using several self-build modules... I did not yet track down which one exactly causes the problem... [16:54:15] The extentions are in /data/project/pywikibot-compat/externals/ [16:54:44] sorry: /data/project/drtrigonbot/pywikibot-compat/externals/ [16:57:37] DrTrigon: It's jseg [16:58:47] Yes, what I wanted to say exactly now... ;) [16:58:59] (could also have been opencv or pydmtx) [17:00:48] Huh, interesting. It appears that the Imagemagic in precise /is/ in fact linked with libjpeg8. It's something else you end up linking against that's linked against the older version. [17:01:01] (It was about time they fixed ImageMagick!) [17:01:10] ;)) yes I wanted to ask whether somebody filed a bug there... [17:01:30] Coren: what about opencv or pydmtx? [17:02:40] Nothing you have in externals/ links to the old libjpeg. [17:02:47] Hmmmmm. [17:03:10] Also, you have a lua interpreter extension for python? :-) [17:04:11] Coren: Of course - I have to go with time - wiki changes to lua so my bots have to be "lua ready"... ;)) [17:04:51] Coren: ...so what to do know? Do I have to track it down first? (I assume so...) [17:05:12] ("now" not "know") [17:05:16] heh. I can't figure out what is trying to link in the old libjpeg. Your best bet is to reproduce the problem while running it under ltrace, try to figure out what is trying to dlopen the old library. [17:06:21] Ok so I will do my job and the come back to you - good thing is I know now that you can help me... :)) Thanks so far! [17:07:05] Since python tends to load things on demand, what you want to look for is mostly instances of dlopen() [17:08:13] I don't know "ltrace" - how does it work? [17:10:57] ltrace your_program your_args. [17:11:09] It sends to stderr all the library calls the program makes. [17:11:17] Sorta like strace does for system calls. [17:23:25] Coren: I'm not fully done but a lot points to jseg (still!) might this be possible? [17:24:31] DrTrigon: It'd dubious. Look at the output of ldd /data/project/drtrigonbot/pywikibot-compat/externals/jseg/segdist_cpp.so; it clearly links to libjpeg.so.8 [17:25:06] * Coren ponders. [17:25:07] Well, wait, if you /built/ that so somwhere else it might have been build against the wrong includes. [17:26:07] Coren: What about the jpeg module inside jseg?? [17:26:28] ("module" -> "library") [17:26:36] ! [17:26:37] There are multiple keys, refine your input: !log, $realm, $site, *, :), ?, {, access, account, account-questions, accountreq, add, addresses, addshore, afk, airport-centre, alert, amend, ask, awstats, bang, bastion, be, beta, bible, blehlogging, blueprint-dns, borg, bot, bots, botsdocs, broken, bug, bz, channels, chmod, cloak, cmds, console, cookies, coren, Coren, cp, credentials, cs, Cyberpower, Cyberpower678, cyberpowerresponse, damianz, damianz's-reset, db, del, demon, dependency, deployment-beta-docs-1, deployment-prep, derp, derpie, doc, docs, domain, dumb, enwp, epad, es, etherpad, evil, excuse, explain, extension, failure, false, fff, filemoves.py, flow, FORTRAN, forwarding, gc, gerrit, gerritsearch, gerrit-wm, ghsh, git, git-puppet, gitweb, google, group, grrrit-wm, hashar, help, helpmebot, herpie, hexmode, hodor, home, htmllogs, hyperon, icinga, ident, IE6, info, initial-login, instance, instance-json, instancelist, instanceproject, ip, is, jenkins, keys, labs, labsconf, labsconsole, labsconsole.wiki, labs-home-wm, labs-l, labs-morebots, labs-nagios-wm, labs-project, labs-putty, labstore3, labswiki, leslie's-reset, lighttpd, limitations, link, linux, load, load-all, log, logs, logsearch, mac, magic, mäh, mail, manage-projects, mediawiki, mediawiki-instance, meh, memo, mob, mobile-cache, monitor, morebots, msys-git, mw, nagios, nagios.wmflabs.org, nagios-fix, namespaces, nc, newgrp, newlabs, newlabs2, newlabs-rl, new-labsuser, new-ldapuser, newweb, night, nocloakonjoin, nova-resource, op_on_duty, openstack-manager, origin/test, os-change, osm, osm-bug, paf, pageant, pang, password, pastebin, pathconflict, pc, perl, petan, petan..., petan:ping, petan-build, petan-forgot, ping, pl, po*of, pong, poof, poofing, port-forwarding, project-access, project-discuss, projects, proxy, pung, puppetmaster::self, puppetmasterself, puppet-variables, putty, pxe, pypi, python, pythonguy, pythonwalkthrough, queue, quilt, ragesoss, rb, reboot, redis, remove, replicateddb, report, requests, resource, revision, rights, rq, rt, rules, Ryan, Ryan_Lane, ryanland, sal, SAL, say, screenfix, search, searchlog, security, security-groups, seen, self, sexytime, shellrequests, single-node-mediawiki, snapshits, socks-proxy, somethingtorelax, srv, ssh, sshkey, start, stats, status, Steinsplitter, StoneB, stucked, sudo, sudo-policies, sudo-policy, sumanah, svn, t13, taskinfo, tdb, Technical_13, terminology, test, Thehelpfulone, tmh, todo, tooldocs, tools-admin, toolsbeta, tools-bug, tools-request, toolsvslabs, tools-web, trout, tunnel, tygs, unicorn, venue, vim, vmem, we, whatIwant, whitespace, whyismypackagegone:'(, wiki, wikitech, wikitech-putty, wikiversity-sandbox, windows, wl, wm-bot, wm-bot2, wm-bot3, wm-bot4, wmflabs, xy, you, [17:26:53] Doh! I just looked at the source... that is exactly what happened. [17:27:10] Coren, you pinged? [17:27:17] For some completely unfathomable reason, that source includes a copy of the old libjpeg6 [17:27:26] Cyberpower678: No, wm-bod did because it's evil. [17:27:30] wm-bot* [17:28:08] :p [17:28:12] DrTrigon: So it tries to build against the includes of libjpeg6 that is stuffed in its own source tree, but the obviously fails since the system libjpeg is 8 [17:28:14] Coren: Can we easily get rid of this code? Is it really needed? [17:30:11] DrTrigon: Well, its makefile has it build explicitly against that jpeg6b, but I unless it somehow needs a bit of the very old API then you should be able to comment that out entirely. [17:31:10] And let it use the system version [17:32:09] I *hope* that's just an included version of libjpeg6b because if it's /patched/ then that makes things considerably harder. Still doable, but then we'd have to build you a static libjpeg to link exactly just that module against. [17:32:41] Coren: ...so essentially just remove "-I./jpeg-6b -L./jpeg-6b" from line 4 and replace it with ... "-Ljpeg" ...? [17:32:55] You don't even need the -Ljpeg [17:33:12] (Since it's in the default paths) [17:33:32] Then rm *.o; make [17:33:32] I'll try and report back... [17:33:52] If you get compile errors, then it needs the old libjpeg and we'll need to build you a static version. [17:41:38] Coren: "djpeg.c:26:69: fatal error: cdjpeg.h: No such file or directory" [17:41:59] (but it should be existing also in jpeg8, or am I wrong...) [18:02:33] Coren: is libjpeg8-dev installed? where is cdjpeg.h stored? [18:57:57] Cyberpower678: ping. doing some serious coding stuff or relishing another cake ? :P [18:58:14] Cyberpower678: In my tool I've added a link to X!'s editcounter [18:58:22] Cyberpower678: https://tools.wmflabs.org/wikiviewstats/index.php?lang=en&page=User:Cyberpower678 [18:59:35] Are you using the edit counter's API? [18:59:55] Cyberpower678: no [19:00:15] Cyberpower678: but I'm about to join Editcounter's OptIn system [19:00:21] You can conserve resources on your end by using the edit counter API. https://tools.wmflabs.org/xtools/pcount/api.php [19:00:29] Now with no BOM. :p [19:00:36] Cyberpower678: ;) [19:01:07] !BOM is Did Cyberpower678 use his crappy editor again? [19:01:08] Key was added [19:01:13] Coren, ^ [19:02:15] !BOManswer is of course he did it again! [19:02:16] Key was added [19:04:21] DrTrigon: cdjpeg.h doesn't seem to exist in libjpeg8 [19:04:39] hedonil, https://tools.wmflabs.org/xtools/pcount/api.php?name=Cyberpower678&wiki=wikipedia&lang=en&format=txt [19:04:42] also supports php formats as well [19:04:59] Cyberpower678: great! [19:06:20] Cyberpower678: As I can see you have *deleted* edits, how about the reverted ones? [19:06:30] hedonil, no I don't, yet... [19:06:56] Which reminds me, I need to contact TParis [19:10:18] Cyberpower678: concerning editcounts, I'm done in my tool. For further info I will use your API then [19:10:28] Cyberpower678: Of course with propper creds [19:10:36] hedonil, it's only a suggestion. It will allow you to conserve resources. [19:11:43] DrTrigon: Ah, that's because it appears that libjpeg8 is provided by libturbojpeg in precise. I'm pretty sure you're stuck using the builtin jpeg62 then; but you'll have to build a static (*.a) library [19:12:13] Cyberpower678: yeah joint venture it is, also known as cooperation [19:13:15] hedonil, I've got plans to add elements of the DUI tool to X!'s edit counter. [19:15:39] Cyberpower678: yeah, heard and read about that tool, it's pretty controversial [19:16:14] hedonil, of course mine will still respect the opt-in requirement. [19:18:09] Cyberpower678: howsoever, I will provide opt-in too and respect the will of the few who want anonymity [19:18:29] Cyberpower678: so everything will be ok then [19:18:29] hedonil, I respect consignsus. [19:21:51] Cyberpower678: respect the freedom of data, the freedom of editors choice, the consensus of community [19:21:53] respect *ALL* the things ;) [19:55:22] is anyone taking care of the disk space issues on the virts in pmtpa? [20:04:08] Ryan_Lane: people have talked about them (before today) and i think there's a ticket too [20:04:16] but no idea if anyone's doing anything [20:04:58] 6540/6541 [20:14:05] well, one fix in (104129) [20:14:12] that took way longer than it should have [20:14:26] openstack is way more of a pain in the ass than it should be to use [20:14:46] I'll be honest in that I still hardly understand how to use keystone's cli [20:46:33] Coren: Comming back to your idea; how can I use a static library (.a) as python module? I don't think that's possible... [20:47:15] DrTrigon: You can't; but you /can/ link your actual module against one. [20:48:15] Coren: So how would your idea work? What would need to be done/changed? [20:48:16] DrTrigon: Look into the jpeg6b subdirectoty, it must have its own makefile and build instructions; you want to compile the static version and not the dynamic one. [20:48:55] That leaves your jseg module the ability to build against and link to that. [20:50:43] Ryan_Lane: Please to comment on https://bugzilla.wikimedia.org/show_bug.cgi?id=58997 [20:50:43] Coren: And that would solve the issue...? Could we install the static jpeg6 on tool-labs? [20:51:16] Ryan_Lane: speaking of openstack pains... see cajoel in #-operations today. (OIT compute cluster) [20:51:45] I'm not in that channel [20:51:46] Ryan_Lane: i was suggesting maybe nova ain't worth the complication for them (and so use e.g. ganeti) [20:51:49] DrTrigon: No, we couldn't. Well, we could but it'd be useless since you wouldn't have the header files (which we can't install). But jseg would take all it needs from your local build and wouldn't have an external dependency on it. [20:51:49] Coren: you dscribed it [20:51:59] I am confused - because in fact the jpeg6 code should be directly build into the binary - why does it need a dynamic lib which I do not compile... [20:52:09] jeremyb: ganeti isn't much simpler [20:52:17] Ryan_Lane: well there's logs. anyway, i just gave the gist [20:52:37] (resp. a static lib) [20:52:37] a simple 2-3 node nova cluster is simple [20:52:37] Ryan_Lane: I was hoping you'd add the other use cases that prompted you to unify the service groups; I listed mine. [20:52:54] Coren: you also listed mine (gerrit) [20:53:18] DrTrigon: Once your .so is linked, you don't /need/ the actual static library anymore; that's used at link time. [20:54:03] Ryan_Lane: a simple ... is simple. aha! :) [20:54:13] yep ;) [20:54:29] assuming local storage and flatdhcp networking, it's easy [20:54:36] Coren: I thought the jpeg6 code is directly built into my library... since I never compiled a dynamic lib of jpeg6. So why do I need to build a static one... [20:54:39] Ryan_Lane: he was planning block storage [20:54:40] well, and using the upstream puppet manifests [20:54:51] I don't see the point in block storage [20:54:59] (I am confused...) [20:55:18] unless you have something relatively reliable backing it [20:55:20] well that's one of ganeti's strong points. the drbd [20:55:33] DrTrigon: That's your issue. It /isn't/ build in. It compiles against its headers, but then relies on the system /dynamic/ library. Which isn't compatible. If you build the static library, and link your so with it, then it'll *actually* be built in and not need the external dependency at all. [20:55:34] I wouldn't consider that a strong point, honestly [20:56:03] well by strong point i mean: thing that gets a lot of people to take a look that wouldn't otherwise [20:56:06] I guess it handles it automatically, but drbd is so, so error prone [20:56:21] orly? [20:56:40] have you ever used drbd? :) [20:56:40] i haven't [20:57:01] Coren: Yes of course... (still confused) I will go over this and report back somwhen... ;) Thanks! [20:57:41] local storage + puppet + backups is better than magic drbd [20:57:41] DrTrigon: tl;dr: make sure your ./jpeg6b is built, that you have a .a, then make sure that when you compile your module it uses it and you're golden. [20:58:01] and likely faster and more reliable [20:58:21] Coren: Sorry one last question; can you explain to me where ImageMagick come into play... its not used in jseg, or am I wrong...?! [20:58:21] I think I'm turning into mark with my hate of shared storage [20:58:22] hah [20:58:42] you mean Coren ? [20:59:02] i at first thought other mark [20:59:02] the other mark [20:59:02] huh. so now Coren can weigh in :) [20:59:23] DrTrigon: In your case, it doesn't. It's just a /common/ case of multiple inclusion of libjpeg, and historically a very frequent one since it long was linked against libjpeg6. In your case, it's not in the picture at all. It's just jseg. [20:59:34] * Coren loves the idea of shared storage. [20:59:41] Too bad there isn't a reliable implementation. [21:00:05] and hasn't been in... ever [21:00:23] what about shared over HTTP? e.g. swift [21:00:35] object storage is different [21:00:43] it's mostly fine [21:01:03] but it doesn't work for posix access [21:01:29] Coren: I see. Do I understand it right that it is not possible to compile and link against any jpeg library (6 or 8) since headers are missing (beacuse of libturbojpeg) - cause this is somehow starnge too... [21:01:44] Well, to be fair, NFS has been doing a very good job for a long time; it just doesn't scale all that well. [21:03:25] DrTrigon: libturbojpeg supports the libjpeg8 API, but not the libjpeg6 one. Only really old code still relies on 6; ImageMagick was one for a long time, apparently jseg is another. [21:03:45] NFS is acceptable at best :( [21:04:07] without using an appliance it tends to be unreliable [21:04:07] and unscalable [21:04:15] Ryan_Lane: It scales; it's just expensive to do it. [21:04:16] pnfs should help, but I doubt it'll ever be usable [21:05:29] Hell, that's /why/ appliances are expensive. [21:05:29] yep [21:05:51] hiya, I need to see a beta-labs log. chrismcmalunch said they're available on deployment-bastion:/data/project/logs , but that host is unknown (and I probably don't have rights). I'm in the deployment-prep project but not an admin of it [21:06:27] spagewmf: You shouldn't need to be an admin to get to deployment-bastion [21:07:28] Coren, what's the full name? ssh: Could not resolve hostname deployment-bastion.wmflabs.org: Name or service not known [21:07:28] Coren: But then I should at least be ablte to try to compile jseg against this lib? So does it have a header file 'cdjpeg.h'? [21:07:48] DrTrigon: That's libgpeg6-specific. [21:07:54] No - it in jpeg8 also... [21:08:03] DrTrigon: Yes, to support the v6 API [21:08:49] spagewmf: You got the right hostname, but you need to reach that from one of the general bastions. [21:08:49] Ryan_Lane, hi, I was just wondering if you guys were going to do anything about https://gerrit.wikimedia.org/r/#/c/91906/ at some point [21:08:49] I see... and this compatibility stuff is missing in turbojpeg [21:08:49] ...? [21:08:51] Krenair: would be nice if someone did [21:09:10] oh I thought you were going to [21:09:10] ok, I might pick up that patch again some time [21:09:14] Apparently. It's the first I hear of it; but I see everything else in Precise is linked against it. [21:09:14] I don't work for wikimedia anymore and my current contract is for migrating labs to eqiad [21:09:30] so I can't really do it right now [21:09:36] andrewbogott_afk: can you take a look at 91906? [21:09:51] (Hasn't done graphic programming since OpenGL 1.1 was fresh and modern) [21:10:10] Ryan_Lane, what? when did this change? [21:10:10] eh [21:10:10] err [21:10:10] heh [21:10:10] my last day was Nov 29th [21:10:14] I'm contracted till Feb 1 [21:10:51] Krenair: And he hasn't got time to do anything but work towards openstack migration. *growl* [21:11:11] :-P [21:11:11] <^d> We're working on a way to physically chain Ryan_Lane to the labs boxen so he can't leave. [21:11:31] well, I'm doing deployment related stuff on my own time [21:11:52] Ryan_Lane: That's because you're cool. :-) [21:13:20] Ryan_Lane thanks for helping out! Who will take over the semantic Nova OpenStackManager extension? [21:13:37] andrewbogott_afk has been mostly doing that for a while anyway [21:37:46] (03PS1) 10Jorm: Bugfixes: [labs/toollabs] - 10https://gerrit.wikimedia.org/r/104142 [21:38:53] Coren, andrewbogott_afk: Just committed some bug fixins to the tool labs page. [21:39:25] fixins', like stuffing and cranberries? :-) [21:40:31] Coren: Thanks a lot - it works!! I have to work all details out and implement it properly but it seams to work! Thanks a lot!! Greetings and GOOD NIGHT! [21:41:03] (03CR) 10coren: [C: 032 V: 032] "And Coren that the patch was good, and seperated the bugs from the good Code." [labs/toollabs] - 10https://gerrit.wikimedia.org/r/104142 (owner: 10Jorm) [21:42:32] DrTrigon: Victory! [21:42:41] Coren: can you look at issues magnus has on labs https://bugzilla.wikimedia.org/show_bug.cgi?id=59007 [21:42:53] and advise [21:43:11] i'm not sure why he's using home directory [21:43:15] Coren: Thanks to YOU! And your patience... :)) [21:43:18] Oh, yeay, broken gluster. Again. [21:45:24] Coren: well, don't have to worry about that much longer [21:46:46] jorm: +2'ed, commited, and pushed to live. [21:47:29] woo hoo! [21:48:09] i love having code pushed to prod without it being a fucking nightmare argument with community members. [21:48:12] * Ryan_Lane really wishes that tools web page would be in mediawiki rather than random php [21:48:35] wold mediawiki be overkill for it, though? [21:48:57] no, because then people could document their tool on wikitech [21:49:17] and it would be discoverable via SMW (or wikidata in the future) [21:49:37] we are running into a similar problem with microsites. [21:49:46] thanks Coren [21:49:53] lots of people want to make sites that are basically brochureware. [21:50:02] and mediawiki is like a gorilla for them. [21:50:04] microsites? [21:50:17] yeah, but we document everything else in wikitech [21:50:47] yeah, like, legal wants a site to explain privacy policy reports, and wp:zero needs a site for documenting stuff to carriers or somesuch, etc, etc. [21:50:48] Ryan_Lane: There's nothing that prevents us from adding a [documentation] link to an apropriate wikitech page per tool; but I'm not a fan of trying to shoehorn everything into mediawiki. There are things wikis are really good at; there are things it's not so good at. Dynamic content is the latter; SMW hacks notwithstanding. [21:51:28] there's nothing dynamic about thsi [21:51:29] *this [21:51:54] the status page is dynamic. [21:52:08] yes, only the status page [21:52:14] and that could be a special page [21:52:51] For that matter, the landing page is -- the fact that the rate of change is low doesn't mean it's not live. If you expect people to document things like change of maintainers, or new tools, you're going to end up with outdated documentation like the toolserver: worse than no documentation. [21:53:04] https://wikitech.wikimedia.org/wiki/Special:NovaResources is a really good example of this [21:53:17] that page is incredibly informative and is awesome [21:53:39] Coren: the list of maintainers can be pulled automaticall [21:53:47] like it is for projects [21:54:02] really the documentation page is just automatically updated [21:54:38] Ryan_Lane: That's a very good /counter/ example, IMO. But meh. [21:55:04] we could also have a magic word that includes the info into pages [21:55:10] which would be dynamic [21:55:30] hrm. must be logged in to view that special page, and i don't have a token. [21:55:44] jorm: you need to be logged in, yes [21:55:59] i don't even know if i have an account. [21:55:59] and unless you've actually created instances it probably won't be too helpful :) [21:56:11] on wikitech? you must [21:56:11] Ryan_Lane: And the gain for that would be... what exactly? When you start having to code extensions and magic words for doing what you need to do on your wiki, you should start questionning whether a wiki was the right things to use in the first place. [21:56:11] you can log into unicorn [21:56:29] Coren: why? most of this is already done [21:56:39] a wiki is just another cms [21:56:59] we extend mediawiki for stuff like this all the time [21:57:28] oop, there it is. [21:57:28] and you get a bunch of free stuff with mediawiki, too [21:57:32] like i18n [21:57:45] and paging, which your custom php needs pretty badly [21:58:13] it also lets the community easily update the display of the info [21:58:19] and have alternative views of the data [21:59:17] And note how horrible the UI is on wikitech and how much javascript you had to layer on top of it to make it barely adequate. Mediawiki is your favorite hammer. :-) [21:59:40] MediaWiki is our organization's hammer [21:59:51] and honestly the tools.wmflabs.org UI isn't very good either [22:00:11] Ryan_Lane: Of course it isn't. I'm a sysadmin, not a UX dude. :-) [22:00:13] wikitech's interface has had 2 engineers working on it and no designers [22:01:06] But I'm not going to hope Jorm is going to be able to make something decent out of Mediawiki for this task. He's already done ++good with tools' small, well constrained page. [22:01:34] Ryan_Lane: Let me try a different tack: [22:02:42] Ryan_Lane: Why are we using anything /other/ than Mediawiki at all? IIRC, we /did/ try the blog on Mediawiki. [22:03:01] (As a good example) [22:03:11] we could honestly use MW for the blog and it would likely be maintained much better than it currently is [22:03:21] our blog is so poorly maintained that we're hiring an outside company [22:03:36] so, that's actually a perfect counter example ;) [22:03:53] Interesting. You see the same things and reach the opposite conclusion. :-) [22:04:37] our use of the blog is amazingly simple. we have basically no plugins installed. a wiki could easily replace it [22:04:51] We'll have to agree to disagree about this; Mediawiki is like emacs. It's got one thing it does very well, and people extended it into doing all those other things it wasn't meant to do until it became a big unusable mess. [22:05:15] MW is just a CMS. [22:05:20] like any other [22:06:06] It's a /specialized/ CMS completely designed around a number of requirements that are useless at best and detrimental to many other uses. [22:06:20] It's meant for collaboratively edited content. [22:06:30] i totally want to watch this conversation but i actually gotta go. [22:06:32] right, which in this case would be nice for tools [22:06:36] * Ryan_Lane waves at jorm [22:06:36] It does /that/ pretty well, even though it's UI is aged. [22:06:51] I like MediaWiki's not-too-complicated UI [22:07:21] Coren: the info that's on tools.wmflabs.org can't be reused or modified in any way right now [22:07:21] It'd be nice for tool /documentation/ [22:07:36] almost everything that's on tools.wmflabs.org is documentation [22:07:57] status fits perfectly with what a special page is [22:08:13] Ryan_Lane: Of course it can be modified: by altering the source. You very much do not *want* it to be modified in any way that does not reflect the technical reality. Having most of what is on tools. editable would be useless or harmful. [22:08:48] And by "most" I really mean "All". I dislike the .description hack and wish that was in LDAP. [22:09:02] description could easily be in ldap [22:09:11] Yeah, it's on my wishlist. [22:09:16] there's a description attribute in ldap [22:09:36] just modify the special page that maintains service groups and add a description field [22:09:47] and have it enter the info into the description field [22:09:48] But that's my point: once that is in LDAP, there is *zero* editable content on tools. Bringing it to a wiki is just silly. [22:09:52] it's like a 10 minute fix [22:10:04] I honestly don't see the point of it being in LDAP [22:10:13] I think it's better for it to be in the wiki [22:10:42] with the description as a semantic property [22:10:56] and as many pages of documentation as wanted [22:11:04] That would make sense iff the wiki was authoritative. It isn't. [22:11:13] why /isn't/ it? [22:11:25] it is for everything else [22:11:29] ... else like what? [22:11:45] ah. I see what you mean. you mean ldap is [22:12:10] Ah, right. That is what I mean. [22:12:49] I don't think it should be for documentation. that's weird [22:13:00] LDAP is a poor place for docs [22:13:56] Probably; though a project description field is no odder than a person description. It /is/ a directory. [22:14:19] that's only useful if multiple applications need to use it [22:14:28] and my argument is that there's no need to be [22:14:37] we create project documentation dynamically [22:14:40] But that's besides the point; I was pointing to .description as the sole user-editable bit not that where it lies needs to be tweaked or whatever. [22:14:57] I don't see why we don't create service group documentation dynamically [22:15:32] Ryan_Lane: Whenever you need a process to track changes to the source of authority in order to edit a wiki, you're introducing a point of divergence. [22:15:36] meh. I should just push in a page that creates service group pages automatically [22:15:41] err [22:15:41] a change [22:15:54] Ryan_Lane: And I'd point the tools landing page at them. [22:16:17] Because the documentation part being wiki'ed /is/ genuinely useful. [22:16:17] it would be a generic solution for service groups, unlike your custom php [22:16:50] It would, and it'd be useful, but it would neither substitute for nor replace the landing page. They do different things. [22:17:11] then I'd add a SMW query that would display the same info as tools.wmflabs.org ;) [22:17:24] Ryan_Lane: You couldn't actually do that. [22:17:33] I can't? why not? [22:17:49] Whatever you do, please let something display a full list of all created tools whether described or not [22:17:50] Ryan_Lane: You'd display editable information that may or may not actually match what's at the source of authority. [22:17:52] it wouldn't show status [22:18:09] Coren: it would be just like the project pages are now [22:18:31] if people start fucking around with them, I'll remove their editing privileges [22:18:54] Ryan_Lane: My point exactly! Why in hell would you bother to invoke a wiki for stuff you want people to not edit? [22:18:56] I could really just make the namespaces uneditable [22:19:08] so that the data can be referenced [22:19:22] and so that it can be put into data that can be pulled elsewhere [22:19:42] why would I bother writing custom code that hides my data somewhere I can't access it? [22:19:43] That's already the case. It's called LDAP, and it was /designed/ to hold a directory of things. :-) [22:19:57] if I add the data to the wiki it can be accessed via a SMW API call [22:20:36] it can be pulled into other pages via a parser function [22:20:47] it can be linked to in special pages [22:21:04] it can be replicated to wikitech-static [22:21:10] You're running in circles now. You want to add the data that cannot be edited to the wiki so that you can use the data in the wiki? If you really wanted to do something cool, make a SMW extension to be able to pull data straight out of LDAP instead. :-) [22:21:13] it can be exported [22:21:23] that already exists [22:21:34] It does? Then why not use /that/ instead? [22:21:55] because that data can't be exported or replicated [22:22:00] All you're doing otherwise is adding a copy of the actual data and hoping it stays in sync. [22:22:04] and it has issues with caching [22:22:34] Of course that data can't be exported or replicated -- that's not a bad thing: you don't want to replicate data for which the source no longer matches. [22:22:51] Incorrect documentation is a million times worse than no documentation. [22:23:16] membership info and existence is always accurate [22:23:26] since the wiki is where that is managed. [22:23:57] so project and service group membership is always going to be right [22:24:11] openstack data is less likely to be accurate since that's asyncrounous [22:24:39] but it's relatively difficult to expose that info otherwise, so we copy it in and we have openstack update the wiki [22:25:02] Ryan_Lane: Indeed. And we know that mechanism failed before. [22:25:16] Coren: this is no different than having a search index [22:26:22] andrewbogott_afk: hm. I have an issue with cross-regional support for creating instances [22:27:28] Coren: either way, it doesn't matter. we could have no SMW data associated and it would still make sense to make this interface in wikitech, via special pages [22:27:47] I need to go eat. I don't think we'll ever agree on that thing because we're approaching this from entirely opposite design philosophies. You see extending Wikitech as a valuable thing, I see it as a tolerable evil at best. [22:28:10] Emacs vs. vi redux. :-) [22:28:21] vi is extended to hell and back too [22:28:30] Ryan_Lane: Sadly. [22:28:35] and it's incredibly useful [22:28:50] Ryan_Lane: I never found a use for any of it. [22:28:57] And I actievly avoid it. [22:29:13] you're missing out on efficiency, then. [22:29:33] vi automatically running pep8 on my python is great [22:29:49] and the syntax highlighting for python, php, etc. is too [22:30:03] (Admitedly, I /do/ use syntax highlighting) [22:30:10] and showing where my 80 char line ends with a vertical line is also awesome [22:30:17] Still need to go eat. [22:30:19] and setting my tab stop to 4 spaces, same [22:30:22] * Coren goes to eat. [22:30:25] * Ryan_Lane waves [22:41:18] hm. it actually seems like it creates the record properly [22:41:33] but it returns the hostname incorrectly on the create instance page [22:41:55] I think addHost returns the wrong host entry [22:43:34] I think because it's looking it up by instanceid? [22:45:25] but looking it up by instanceid with no idea of the region [22:49:13] hm. I think maybe we should always look instance id up by region. [22:49:25] * Ryan_Lane takes a look at the code to see how hard this refactor woul dbe [22:50:17] a region always has a dns domain associated with it [22:51:51] it almost looks like we should split public hosts apart from private hosts [22:56:47] split, like, put them under different ous? [22:56:51] nah [22:56:56] the code into two classes [22:57:08] I think it's not necessary, though [22:57:09] Oh, yeah, it's already almost split. [22:57:19] I mean, same class but separate functions mostly. [22:57:41] the class is only ever used via factory methods anyway [22:58:31] so I could simplify the constructor to only return an object, then the factory methods can set things like public, private, region, etc, then have it load itself through loader methods [22:58:42] and return the object that way [22:59:04] both the public and private code do share some of the same code [22:59:39] and they share a lot of the same interface