[00:02:01] bd808: wow, fatal.log looks pretty. is this your doing? :) [00:02:10] yes :) [00:02:36] awesome, nice work [00:03:02] https://gerrit.wikimedia.org/r/#/c/233590/ [00:04:39] it should be all pretty by the end of the day tomorrow when 1.26wmf22 is everywhere [00:05:02] bd808: is there a way to override a hiera setting from a vagrant role? [00:05:15] nope [00:05:45] there have been times when I really wanted to but we don't have any way to do that [00:05:59] hiera is outside of puppet [00:06:59] are you looking for a "if role X is enabled, do Y differently" sort of solution? [00:07:07] yes [00:07:27] I was thinking of creating a role for the LTS branch [00:07:41] ah. make it a separate wiki [00:07:55] there is code for that in the fundraising stuff [00:08:07] that wouldn't be very useful [00:08:28] I need to test private image handling in 1.23, for example [00:08:42] there is a private role, which already creates its own wiki [00:13:03] tgr: so `vagrant hiera mediawiki::branch whatever` does what you want, but you'd like a role to apply that? [00:14:00] there is probably some sort of hira magic we could do actually to let roles set things, but conflict resolution would be tricky [00:14:02] bd808: basically, what would be needed is to make hiera fragments like modules/role/hiera/my_role.yaml and make vagrant add those into hiera.yaml when someone changes the role list, right? [00:14:35] anyway, no, vagrant hiera sounds fine [00:14:58] assuming no ugly hacks are needed for 1.23 [00:15:19] the `vagrant hiera` command is an editor for puppet/hieradata/local.yaml [00:15:42] the 1.23 hack thing I'm not sure about [00:16:00] like what config we have that is 1.2x specific [00:16:01] will see that soon [00:16:14] did 1.23 run under hhvm? [00:16:20] if you weren't dealing with the mediawiki role, you could simply create a wrapper role that did `class { 'mediawiki': branch => ? }` [00:16:42] but role::mediawiki is always enabled, so that's not possible here [00:17:11] i.e. setting parameters explicitly overrides hiera [00:18:32] also, i remember us having a conversation about allowing role parameters to be given via `vagrant roles enable` but we never implementing [00:18:43] yea we talked about it [00:18:44] *implemented* it [00:18:50] i'm kind glad we didn't [00:18:59] that was part of the doc header thing I think [00:19:07] mw-vagrant doesn't need more complexity [00:19:17] oh yeah, you're right [00:19:58] we took ori's pretty and simple tool and made it into a monster [00:20:31] it's quite the swiss army sink [00:21:36] I'll take the blame for most of the really nasty changes (multiwiki, hiera) [01:22:10] bd808: do you think backporting a minimal composer.json to 1.23 could cause problems? [01:22:36] right now vagrant explodes because of the lack of composer support [01:23:40] is it just php::composer::install that hates it? [01:24:15] adding composer.json in 1.24 was not a fun process [01:24:35] I'd hate to break things for another set of SMW users who have stuck with 1.23 [01:26:07] for your testing right now can't you just stub it in locally? [01:27:45] I could, sure [01:28:15] we could fix php::composer::install to be smarter too [01:29:15] the problem with adding composer.json is that a traball unpack will overwrite any composer.json that a user may have to support SMW and other extensions that (yuck) install via composer [01:29:24] but 1.23 is supposedly the supported LTS branch until next May, and if you need to patch your VM to be able to test on it, that probably does not improve that support [01:29:45] I'll just add a test to the composer rule then [01:29:49] actually may 2017 [01:30:12] so yeah making it work work with mw-v is a good idea [01:30:46] but better to hack up mw-v than to sneak a braking change into 1.23.11 [01:57:15] bd808: given a hiera file with a: foo, b: "%{hiera('a')}" when I run "vagrant hiera a bar" that changes a but does not change b (or so I think, haven't found out what is the good way to debug these) [01:57:38] are hiera references in a file resolved before it moves on to the next file? [04:41:04] tgr|away: I'm not actually sure. I *think* that a quoted string reference like that is resolved when the key is called for but I'm not sure. [04:43:40] tgr|away: who has mwoauthmanageconsumer rights now? The group on meta shows as empty -- https://meta.wikimedia.org/w/index.php?title=Special:ListUsers&group=oauthadmin [04:48:50] bd808: I figured it out in the meanwhile, my actual problem was that class parameters are looked up in hiera but defined type parameters are not [04:49:12] that is true, yes [04:49:47] defined types can be generated from hiera data using a puppet function but defaults never come from that otherwise [04:49:52] uhh, I thought OAuth admins were a global group [04:50:09] I'll port the users from mw.org [04:50:51] yeah, I ended up with this ugly thing: https://gerrit.wikimedia.org/r/#/c/237321/2/puppet/modules/mediawiki/manifests/skin.pp [04:53:38] that should work. seeing hiera mentioned in puppet classes kind of creeps me out but I know we do things like that in ops/puppet in several places [05:01:40] OAuth admins are in sync on meta and mw.org now [05:03:54] cool [05:03:58] maybe just using $::mediawiki::branch would give the same result without the hiera-ness? I still don't quite understand when exactly the autobinding or whatsitsname happens [05:04:28] $::mediawiki::branch should work I think [05:05:00] its worth testing anyhow [05:06:33] * bd808 hopes an oauthadmin sees https://meta.wikimedia.org/w/index.php?title=Special:OAuthListConsumers/view/aea31746a1e5d5b3e7514952f70e7035&name=&publisher=&stage=0 [05:07:47] I can do that [05:07:57] are you using it to record submitters? [05:08:48] yes, it will add their wiki username in the record that is created in elasticsearch [05:09:07] in the currently undisplayed "nick" field [05:09:38] at some point I want to add tracking of what quips a user has voted up/down [05:09:53] but for now it's a free for all [05:10:50] ugh, why don't we have a link from the OAuth description page to the administration page? [05:11:22] because you haven't added on yet :) [05:11:34] *one [05:14:48] also the log is a mess [05:15:12] probably not a bad idea to actually use the thing before deciding what UI improvements need to be done [05:16:06] it needs love in lots of places [05:16:18] we'll get there I think [05:17:15] thanks [05:17:52] add "should send an echo notification on approval" to the list of missing things [05:19:36] that's actually pending review [05:20:00] https://gerrit.wikimedia.org/r/#/c/231989/ [05:30:39] * bd808 slinks off to bed [17:52:15] csteipp: are you comfortable +2'ing https://gerrit.wikimedia.org/r/#/c/234917 ? I can try to get Niharika to do it if you are not [17:53:07] bd808: I'll do it [17:53:12] bd808: I meant to ask you about how to go about testing it. :) [17:53:21] thanks! [17:54:09] Niharika: there is a small instruction in the comments but it doesn't tell the whole story. My quips app uses it [17:54:28] Ah. [17:55:44] You can actually use it at https://tools.wmflabs.org/bash/ so that's one kind of test :) [17:56:45] That's one test passed. [18:00:30] RoanKattouw: your feature request to add quips via web is not a reality -- https://tools.wmflabs.org/bash/help#add-web [18:00:38] s/not/now/ [18:01:11] hah [18:01:14] *yay [18:01:20] Wow that was a weird typo [18:01:32] off by one errors [18:28:33] bd808: nice [22:12:56] anyone up for a quick trivial CR? https://gerrit.wikimedia.org/r/#/c/237515/1/resources/src/mediawiki.less/mediawiki.mixins.less [22:17:06] commented [22:19:28] thanks [22:19:43] testing it [22:19:47] (your suggestion) [22:21:54] yes, it works [22:21:55] and is cleaner [23:18:30] csteipp-ish: any time to look at https://gerrit.wikimedia.org/r/#/c/205528/ ? (just for a +1) [23:24:40] AaronSchulz: Yeah, I'll look at it on the train