Architecture meetings/RFC review 2014-03-19

21:00 UTC, March 19th, at.

Requests for Comment to review

 * 1) MVC framework - Owen Davis
 * 2) Structured logging - Ori Livneh, Bryan Davis, and Aaron Schulz. Second discussion, following up on 2013-12-04 meeting

Meeting summary

 * 1) MVC framework
 * 2) * Previous discussion: Architecture_Summit_2014/HTML_templating
 * 3) * Current discussion: on talkpage and current wikitech-l thread on "what are HTML templates systems anyway"
 * 4) * action: Gabriel to add Nirvana to https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance
 * 5) * the logs from our last RFC discussion of HTML templates stuff include some thoughts from Trevor
 * 6) * action: sumanah  ask about Nirvana interest among WMf engineers (prerequisite to any other action items on this topic)
 * 7) * Knockoff is our Knockout workalike  https://github.com/gwicke/knockoff
 * 8) * in terms of security model,  nirvana is basically QuickTemplates++ yes
 * 9) * discussion of HHVM & async pull
 * 10) * action Owyn will respond to http://www.gossamer-threads.com/lists/wiki/wikitech/442532
 * 11) Structured logging
 * 12) * This is our second discussion of this, following up on https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-12-04
 * 13) * https://gerrit.wikimedia.org/r/#/c/112699/ strawman implementation in Gerrit
 * 14) * According to Bryan on March 14th http://www.gossamer-threads.com/lists/wiki/wikitech/441656 "At this point the most controversial aspect of my proposed implementation seems to be importing third-party libraries into mw-core and/or the use of composer to manage that activity. I would welcome discussion of alternatives or consensus that this is a reasonable approach for the immediate future that should be revisited if and when a better idea is found for the general problem."
 * 15) * according to Bryan today: "I just want Tim to say he'll +2 the patch :)"
 * 16) * But yes, I need to find the way that we can use the external libraries in core or be told that's not how we do things here.
 * 17) * action Bryan to update the onwiki RfC with details from https://gerrit.wikimedia.org/r/#/c/112699/
 * 18) * action bd808 get someone to +2 his changeset
 * 19) *  we've had good luck putting all the logs in elastic search and just querying it
 * 20) * bd808 "interested in fine grained runtime control"

Action items

 * Gabriel to add Nirvana to add it to https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance
 * sumanah  ask about Nirvana interest among WMf engineers (prerequisite to any other action items on this topic)
 * Owyn will respond to http://www.gossamer-threads.com/lists/wiki/wikitech/442532
 * ✅ Bryan to update the onwiki RfC with details from https://gerrit.wikimedia.org/r/#/c/112699/
 * bd808 get someone to +2 his changeset

Full log
[21:00:26] 	 #startmeeting RFC review of MVC & structured logging proposals | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) [21:00:27] 	 Meeting started Wed Mar 19 21:00:26 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:27] 	 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:27] 	 The meeting name has been set to 'rfc_review_of_mvc___structured_logging_proposals___channel_is_logged_and_publicly_posted__do_not_remove_this_note_' [21:00:27] 	 #chair brion TimStarling [21:00:27] 	 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-19 [21:00:27] 	 Warning: Nick not in channel: brion [21:00:28] 	 Current chairs: TimStarling brion sumanah [21:00:42] 	 hello [21:00:46] 	 Ah, there's OwynD! [21:00:51] 	 OK, OwynD you're first :) [21:00:56] 	 #topic MVC proposal [21:00:56] 	 #link https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework [21:01:01] 	 so... i was under the mistaken impression that this was an in-person meeting, so i'm at the foundation office. :/ [21:01:21] 	 the office staff is very confused [21:01:44] 	 OwynD: I apologize! I am sorry for not explicitly specifying in my mention to you that it was IRC ONLY [21:02:01] 	 #new-montgomery [21:02:05] 	 ha [21:02:15] 	 Somebody should show OwynD the transporter pad in the closet that leads to Tim's house [21:02:28] 	 oh if only! [21:02:28] 	 OwynD: where exactly are you? [21:02:41] 	 sitting in the 6th floor lobby [21:02:46] 	 !link https://www.mediawiki.org/wiki/Talk:Requests_for_comment/MVC_framework [21:03:04] 	 OwynD: I'll come upstairs and get you :-) [21:03:10] 	 gabriel is here [21:03:30] 	 i'll come down to 3rd then we will start [21:04:11] 	 OK [21:04:31] 	 (I mentioned that it was IRC, but I didn't say IRC only) [21:05:31] 	 just arrived downstairs [21:05:35] 	 ok, let's begin then. what's the process? [21:05:50] * aude waves� [21:05:55] 	 ok hi OwynD [21:05:56] 	 still no brion? [21:06:29] * rdwrer waves� [21:06:29] 	 OwynD: Well, I usually ask the RFC authors what they'd like out of today's discussion [21:07:02] 	 such as a decision on a particular subtopic, or an approval of the whole RfC [21:08:17] 	 OwynD: So I ask that of you :) [21:08:45] <TimStarling>	 in terms of templating systems, nirvana seemed to be the odd one out, out of those presented at the architecture summit [21:09:00] <TimStarling>	 it was coming from a very different design direction to the others [21:09:03] <OwynD>	 well, the main difference that i see between the proposals is that one is a more specific solution for building special pages (nirvana) [21:09:10] 	 !link https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating#Nirvana_Templates [21:09:14] <OwynD>	 and the other is a much more general purpose templating solution that could be used elsewhere [21:10:02] <OwynD>	 nirvana was also an attempt to isolate some of the wikia code from the core mediawiki code (ended up re-implemeting some stuff, like an ajax entry point) but the templating part of it can be separated. [21:10:34] 	 OwynD, where do you see the strengths of Nirvana vs. something like Handlebars or Knockoff? [21:10:59] <OwynD>	 and the other goal with making the proposal was just for wikia to get more involved in the process as a way of learning about it, which i think has been achieved. [21:11:24] 	 #link http://www.gossamer-threads.com/lists/wiki/wikitech/442532 current wikitech-l thread - summary of "what are HTML templates systems anyway" [21:11:28] <OwynD>	 well, one "advantage" is that it's PHP. :) [21:11:44] <TimStarling>	 presumably it's fast [21:11:50] <MaxSem>	 OwynD, we're looking for PHP and JS engine [21:11:53] 	 we should add it to https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance [21:12:24] <OwynD>	 the other advantage from my perspective was that it allowed (but doesn't really enforce) some separation of business logic from template/formatting logic. [21:12:30] 	 the LightnCandy Handlebars implementation (which compiles templates to PHP code) is currently the fastest PHP library in the tests [21:12:37] <TimStarling>	 there's been a lot of talk about security properties of various template engines [21:12:38] 	 is Knockoff our cutesy name for our Knockout workalike, or is that just a persistent thinko? [21:12:42] <OwynD>	 our custom skin was getting totally unweildy. [21:12:51] <TimStarling>	 and I gather nirvana is on a par with QuickTemplate in that respect [21:12:51] <OwynD>	 so, nirvana was designed as a framework for building our new Skin [21:13:00] 	 robla, https://github.com/gwicke/knockoff [21:13:03] <TimStarling>	 i.e. it relies a lot on the template author being aware of security [21:13:18] <OwynD>	 nirvana is basically QuickTemplates++ yes [21:13:26] 	 robla: so yes, cutesy [21:13:36] 	 :-) [21:14:03] 	 #action gwicke add Nirvana to add it to https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance [21:14:29] <OwynD>	 the framework also allowed us to develop new parts of the skin as extensions and "plug" them in really easily. [21:14:34] 	 heh, maybe I can get OwynD to add it to https://github.com/gwicke/TemplatePerf ? [21:14:55] <OwynD>	 but in that sense it's not really a part of the framework, it's just a way of organizing the massive amounts of code / developers we have all working on the same codebase. [21:15:06] <OwynD>	 oh sure, i can do a performance thing [21:17:07] <TimStarling>	 I would like to know if anyone from WMF is in favour of the concept, compared to other proposals [21:17:49] <OwynD>	 basically inez and I just didn't like that QuickTemplates are sort of an object at the top and a template at the bottom. :) [21:17:50] <MaxSem>	 I see no benefit over our existing templates. and it's PHP-only [21:17:54] <TimStarling>	 because I don't want to waste OwynD's time writing RFCs and doing benchmarks if it doesn't have any chance of actually being used [21:18:08] 	 Iirc, Trevor seemed interested in it at the arch summit [21:18:13] 	 TrevorParscal: ^ [21:18:31] <OwynD>	 he was interested in the fact that it sort of inverts the normal data flow in a template system. [21:18:42] <OwynD>	 that is, the template asks for data [21:19:03] 	 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21 - the logs from our last RFC discussion of HTML templates stuff include some thoughts from Trevor [21:19:10] <OwynD>	 and then a controller supplies that data (with the appropriate sub-template) [21:19:25] 	 I also like the pull aspect, but it is not completely unique to nirvana [21:19:50] <TimStarling>	 the template engine I wrote back in like 2006 was pull based [21:19:53] 	 calling lambdas from the model is similar [21:20:39] <TimStarling>	 but it had registered callbacks rather than actually having the template call PHP code [21:20:45] <TimStarling>	 kind of lisp-like [21:20:55] 	 we were thinking about async pull, similar to parsoid [21:21:32] <TimStarling>	 have you looked at HHVM's threading model at all? [21:21:46] 	 MaxSem: when you say "our existing templates" what specifically do you mean? [21:21:56] <MaxSem>	 QuickTemplate [21:22:01] 	 I haven't, but that's fairly orthogonal to how you hook calls to it up and manage async returns [21:22:03] <OwynD>	 existing templates are QuickTemplate and the HTML builder object [21:22:19] <TimStarling>	 threads are completely isolated in terms of variables etc., like PHP's thread extension [21:22:43] 	 whether stuff is processed on a thread or a different machine does not really matter much [21:22:44] <OwynD>	 we didn't like the HTML thing either, although gwike's proposal has the safety features that are part of that XML/HTML object approach [21:23:15] <TimStarling>	 and it has string message passing, "pagelets" and RPC [21:25:23] 	 TimStarling: ok, so do you perhaps want us to ask about Nirvana interest among WMf engineers, mark that as an action item (prerequisite to any others), and move on to structured logging? [21:25:55] <TimStarling>	 yes, ok [21:26:07] * sumanah presumes there is probably face-to-face conversation happening at WMF office right now including OwynD & gwicke as well :-)� [21:26:23] <OwynD>	 there's a bit of side chat.  i will type in some comments. [21:26:24] 	 #action sumanah  ask about Nirvana interest among WMf engineers (prerequisite to any other action items on this topic) [21:26:25] 	 yeah, sorry; he is sitting right next to me [21:26:34] 	 perhaps there are some aspects of it that we like [21:26:47] <TimStarling>	 someone has to really want nirvana specifically if we are going to use that [21:26:49] 	 we were just talking about async processing [21:27:10] <TimStarling>	 which I think is unlikely, although I haven't talked to Trevor [21:27:28] <TimStarling>	 I think more likely is some kind of template engine recommended by WMF and integrated into the core [21:27:31] <OwynD>	 so, i looked at doing async rendering, and the benefit wasn't worth the complexity of doing it in pure PHP, but HHVM makes that more feasible. [21:27:32] * sumanah waits a minute for last comments on Nirvana/MVC/templates before changing topic. bd808 you're up in a min� [21:27:42] <TimStarling>	 and perhaps that could be integrated with the non-template bits of nirvana [21:27:48] 	 basically my outcome from looking at async stuff was that the template interface does not need to change; the main change would be in the interface for lambdas and bindings [21:27:56] 	 they'd receive an extra cb parameter [21:28:10] 	 #info Knockoff is our Knockout workalike https://github.com/gwicke/knockoff [21:28:23] 	 #info in terms of security model, <OwynD> nirvana is basically QuickTemplates++ yes [21:28:31] 	 sync lambdas could just ignore that and directly return a non-void result [21:29:45] <OwynD>	 so, i was just happy to have people take a look at and criticize Nirvana in the context of what the future needs of Mediawiki are... [21:29:47] 	 #info discussion of HHVM & async pull [21:29:59] <OwynD>	 it's sufficient for what Wikia is doing, but we're not very ambitious in that department. :) [21:30:00] 	 OwynD: shall we continue this discussion on the mailing list then? [21:30:16] 	 OwynD: perhaps in the wikitech-l thread I started about what HTML templates are and what our choices are? [21:30:17] 	 (the async bit is basically a rough description of parsoid token processing) [21:30:21] <OwynD>	 sure, i'll respond on that thread. [21:30:39] 	 #action Owyn will respond to http://www.gossamer-threads.com/lists/wiki/wikitech/442532 [21:30:49] 	 ok! [21:30:50] 	 #topic Structured logging proposal [21:30:50] 	 #link https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging [21:30:50] 	 #info This is our second discussion of this, following up on https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-12-04 [21:31:05] 	 (thanks OwynD!) [21:31:13] 	 #link https://gerrit.wikimedia.org/r/#/c/112699/ strawman implementation in Gerrit [21:31:21] 	 #info According to Bryan on March 14th http://www.gossamer-threads.com/lists/wiki/wikitech/441656 "At this point the most controversial aspect of my proposed implementation seems to be importing third-party libraries into mw-core and/or the use of composer to manage that activity. I would welcome discussion of alternatives or consensus that this is a reasonable approach for the immediate future that should be revisited if and when a better i [21:31:21] 	 dea is found for the general problem." [21:31:35] 	 er, "if and when a better idea is found for the general problem." [21:31:44] 	 sumanah: You did all the work for me. :) [21:31:45] 	 #info according to Bryan today: "I just want Tim to say he'll +2 the patch :)" [21:31:53] 	 #info But yes, I need to find the way that we can use the external libraries in core or be told that's not how we do things here. [21:32:06] 	 bd808: Happy to, when I can! [21:32:50] 	 csteipp: is Brion anywhere nearby? :/ [21:33:08] 	 So my first question is has anyone looked at the proposed interface and implementation and not commented in gerrit? [21:33:09] 	 sumanah: No, haven't seen him today [21:33:28] * bd808 is hoping to find closet supporters� [21:33:41] <TimStarling>	 who is saying you can't have external libraries? [21:34:10] 	 the comments on the patch, basically [21:34:33] 	 I haven't looked yet, but we have recently done something very similar in parsoid [21:34:37] 	 Several people seemed to think that putting libraries in mw-core.git was gross [21:34:53] 	 I tried to do it in as nice a way as I could [21:35:04] 	 the possibly interesting bit we have is hierarchical log levels, so we are doing stuff like warning/api [21:35:10] <OwynD>	 wikia uses a simple logging framework based on monolog, which i believe is what this proposal is... [21:35:12] 	 backends can subscribe to those by regexp [21:35:26] 	 There is a new libs/ directory that uses composer to manage the files so we can upgrade in the future [21:35:46] <TimStarling>	 bd808: who specifically? [21:36:14] 	 parent5446 and mwjames [21:36:34] 	 from a skim of https://gerrit.wikimedia.org/r/#/c/112699/ it looks like Jeroen had objections but they were resolved [21:36:49] 	 there is a side discussion on how wiki is also using monolog and logstash here [21:36:50] 	 Jeroen had some concerns initially but I think … yes sumanah beat me to it [21:36:53] 	 *wikia [21:36:58] <TimStarling>	 well, tyler removed his -1, but is still recommending a git submodule, right? [21:37:29] 	 TimStarling: I think that's correct, yes [21:38:05] 	 dd [21:38:09] 	 tus [21:38:15] 	 I really hate submodules, but I wouldn't make my dislike of them a blocker if that's the right way forward [21:38:36] 	 ebernhardson: wrong window? :-) [21:38:52] * YuviPanda blames ebernhardson's cat.� [21:38:53] 	 sumanah: :( didn't disable trackpad [21:38:54] <TimStarling>	 how do you upgrade the libs with composer exactly? [21:39:29] <MaxSem>	 I too think that submodules in core are bad because it kills the existing "ready to work after 1 git pull" model [21:40:00] 	 You would change the composer.json and then run `composer update` and it would pull the new version into your local working copy [21:40:18] <TimStarling>	 I would rather not have any submodules in a production branch, except submodules which point to our own repos [21:40:19] 	 Then it would be git add and commit to push as a gerrit patch [21:40:23] <TimStarling>	 otherwise there are security implications [21:40:54] 	 I used a similar model in building the scholarships application [21:41:06] <TimStarling>	 even if you specify a version, you're still giving everyone with force push access to the remote repository the ability to own the server [21:42:57] <OwynD>	 one alternative to git submodules is subtree merging. [21:43:09] 	 http://git-scm.com/book/ch6-7.html [21:43:19] <OwynD>	 one of our developers was just looking at that as a way of tracking the VE repo from inside the wikia repo [21:44:08] <OwynD>	 basically you pull the remote repo into a branch, and then check that branch out into a directory. [21:44:09] 	 hey ori. log so far: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140319.txt (currently talking about structured logging) [21:44:11] 	 Is there anything in particular that gains you over just having the files in the same repo? [21:44:34] <OwynD>	 well, the original repo is actually remote. [21:44:47] 	 it looks like the ability to pull in upstream changes is preserved [21:44:48] 	 sumanah: thanks very much for that [21:44:56] 	 ah, sure [21:44:57] <OwynD>	 yeah, exactly [21:45:48] 	 My management with composer should allow the same (importing new upstream). It worked well in schaolarships. [21:46:59] 	 I think I just got a good endorsement on the patch. :) [21:47:29] 	 Are there other questions people have other than the library management aspets? [21:47:34] 	 *aspects [21:47:44] 	 bd808, in parsoid we were able to support tracing with the prefix matching mechanism I mentioned earlier [21:48:06] 	 do you think that could be useful in PHP too? [21:48:07] 	 gwicke: hierarchal loggers? [21:48:35] 	 that would require you to log to a specific logger at the source, wouldn't it? [21:48:44] <OwynD>	 that RFC does a good job of summarizing the current state of logging, but then it contains this: [21:48:45] <OwynD>	 FIXME: Propose a PHP API for logging and a migration plan for existing wfErrorLog calls [21:49:02] 	 with the prefix matching you can start listening to an arbitrary regexp at any time [21:49:27] 	 per backend [21:49:30] 	 OwynD: Yes. I need to update the wiki doc. The patch at https://gerrit.wikimedia.org/r/#/c/112699/ is the real stuff [21:49:35] <OwynD>	 ok, cool [21:50:01] 	 gwicke: So you are doing that with log levels? [21:50:08] <OwynD>	 wikia is basically using the PSR functions (info,debug,warning etc) and API ($message, $context) with monolog as the backend [21:50:10] 	 yes, stuff like warning/api [21:50:13] * bd808 tries to find the scrollback� [21:50:42] <OwynD>	 it works for us, so that would be a +1 from our perspective [21:50:45] 	 that's matched by a warning backend, but you can also subscribe to (trace|warning)/api [21:50:46] 	 Isn't that the same as warning level on the api channel? [21:51:13] 	 the level does not let you drill down to an area [21:51:23] 	 a flat level, that is [21:51:53] 	 our tracing output is very verbose, so tracing everything is not feasible [21:52:04] 	 But channels do if they are used well, and your level suffix needs the same care [21:52:04] 	 so we always narrow it down to some area of the code [21:52:20] 	 #action update the onwiki RfC with details from https://gerrit.wikimedia.org/r/#/c/112699/ [21:53:17] 	 bd808, so channels are what you log to in the code? [21:53:25] 	 I'm not quickly seeing the difference between "show me level (trace|warning)/api" and "show me trace and warning messages on the api channel" [21:53:43] 	 gwicke: Yes. A channel == a named logger [21:53:50] 	 we have warning/api/foo as well [21:53:59] 	 you can be arbitrarily precise [21:54:48] 	 handy if you just want to log timeout errors from api template expansions for example [21:55:07] 	 That bit would be nice. monolog doesn't support logger hierarchies out of the box [21:55:20] 	 we implemented that in our internal interface only [21:55:23] 	 ok, we're running out of time -- any particular #info to note or next actions or #agreed decisions? [21:55:25] 	 monolog would just be the backend [21:55:38] 	 it doesn't need to know about the filtering [21:55:41] 	 You could add other metadata that would surface the same thing via logstash searches [21:56:06] 	 you can't trace everything all the time [21:56:37] 	 besides generating a ton of output it also takes up a good amount of cpu time, at least in parsoid [21:57:00] 	 gwicke: Ah. I get you point more now. You're interested in fine grained runtime control [21:57:12] 	 yup [21:58:03] 	 That would be interesting but I think out of the scope of the initial implementation here [21:58:27] 	 if you start with a string log level for now then you can add that later [21:58:36] 	 if you use magic constants that would be harder [21:58:41] 	 Mediawiki doesn't have a stellar real-time configuration management layer yet across the cluster [21:59:08] 	 I'd really like to stick to the PSR-3 interface as closely as possible [21:59:34] 	 That's the PHP "standard" for logging [21:59:56] 	 we'd probably need a separate trace system then [22:00:14] 	 or rather, a separate way to filter on verbose trace output [22:00:14] <TimStarling>	 "not stellar": hehe, that's very generous [22:00:27] <OwynD>	 we've had good luck putting all the logs in elastic search and just querying it [22:00:50] <OwynD>	 so, you can probably just punt on that as well, keep the simple interface and just process/filter them offline [22:01:06] 	 That's working pretty well for us too. Now I just want richer data to feed to logstash [22:01:25] 	 And an easier way to plug in a new transport [22:01:49] 	 So what are my TODOs? [22:02:04] 	 Update the wiki page [22:02:15] 	 Anything else? [22:02:26] <TimStarling>	 get someone to +2 the change? [22:02:38] 	 :) [22:02:43] 	 Cool [22:02:59] 	 #action bd808 get someone to +2 his changeset [22:03:09] 	 #info <OwynD> we've had good luck putting all the logs in elastic search and just querying it [22:03:18] 	 #info bd808 "interested in fine grained runtime control" [22:03:52] 	 I don't know what else to take from this conversation that others might also want to know [22:03:59] <TimStarling>	 ok, I've got to go to the next meeting [22:04:03] 	 #endmeeting