18:00:50 <TheSnide> #startmeeting 18:00:50 <MeetBot> Meeting started Tue Oct 29 18:00:50 2013 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:50 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:07 <TheSnide> woo. on time today! 18:01:14 <TheSnide> hi everyone! 18:02:08 <TheSnide> so, agenda for today is quite common : 2.2, munin-c, q&a. 18:02:37 <TheSnide> feel free to talk when you want. (as usual) 18:02:46 <TheSnide> #topic 2.2 18:03:37 <TheSnide> sql branch is progressing again. the overview and service page are done. 18:03:52 <TheSnide> current work is on the node page. 18:05:04 <TheSnide> sql is very easy tp work with. 18:05:45 <TheSnide> it even makes up for very readable code. 18:06:54 <TheSnide> imho, and compared to old. 18:08:09 <TheSnide> the html datastruct is not. reverse eng it is easy, but very time consuming. 18:09:40 <TheSnide> nice part is I think i'll might rewrite the graph CGI and limits also, to make use of the SQL backend. 18:10:08 <TheSnide> dunno if it'll be ready for 2.2 18:13:55 <GrumpyFux> re 18:14:09 <GrumpyFux> sorry, the road were terrible 18:14:39 <GrumpyFux> will add my agenda points when appropriate 18:15:39 <TheSnide> speed of cgi+sql is quite decent. currenlty 100ms for 200+ nodes in plain CGI mode (no FCGI yet) 18:16:04 <TheSnide> so, that's it for 2.2 18:26:50 <TheSnide> question ? 18:29:23 <GrumpyFux> Hm? 18:30:33 <olasd> do you have an idea of the "initialization overhead" 18:30:46 <olasd> (i.e. what proportion of those 100ms will be gained through fcgi) 18:33:54 <TheSnide> olasd: no idea. 18:34:07 <olasd> right :0 18:34:10 <olasd> :)* 18:36:00 <TheSnide> but i'm afraid that init time is fairly minimal, since the cgi is now only 1 file. 18:36:49 <TheSnide> which is about 6KiB long. 18:40:28 <TheSnide> ... and about 200 LoC. 18:40:48 <TheSnide> SQL is *very* expressive. 18:41:28 <TheSnide> #topic munin-c 18:41:38 <TheSnide> so, moving to munin-c 18:42:12 <TheSnide> in order to focus on sql, i asked helmut to take the interim on m-c. 18:43:07 <TheSnide> i made several pull req on various feats. 18:43:34 <TheSnide> the biggest one being config parsing, that should be the same as mainline munin-node. 18:43:43 <TheSnide> (hint, it isnt yet) 18:44:32 <TheSnide> i'm also busy deploying it to many win32 nodes. currently via cygwin. 18:47:09 <TheSnide> the win32 port does benefit from a new, external_ plugin, that completely delegates the actual data gathering to an external process. 18:47:31 <TheSnide> like the procmon or some powershell tools 18:48:37 <TheSnide> ... as the current m-c policy is not to have "more" feats than mainline, i'll write an shell based external_ official plugin also. 18:50:45 <TheSnide> end. questions ? 18:51:51 <TheSnide> #info in order to focus on sql, i asked helmut to take the interim on m-c. 18:52:22 <TheSnide> #topic misc 18:52:34 <TheSnide> now, free-for-all ! :) 18:52:49 <GrumpyFux> I'd like to discuss up to four things 18:53:00 <GrumpyFux> first, bugs and handling of them 18:53:39 <GrumpyFux> I checked a lot of recent bug reports, quite a lot of them just should be applied 18:53:45 <TheSnide> #topic misc/bugs 18:54:24 <TheSnide> you mean they contain patch ? 18:54:35 <GrumpyFux> often they do 18:55:04 <GrumpyFux> Aside, I was thinking about a bot that gates new tickets and comments on tickets into this channel 18:56:29 <GrumpyFux> So, honestly, my impression is the bug tracker doesn't get that much attention 18:57:28 <TheSnide> it doesnt. that is a fact. 18:57:43 <TheSnide> a sad one, but nonetheless a true one. 18:58:05 <TheSnide> #action add an irc trigger on trac actions. 18:59:03 <GrumpyFux> So, should I create a git branch somewhere with the patches I consider sound? Would that help? 18:59:31 <GrumpyFux> However, patches that _I_ created should be reviewed by somebody else 19:00:09 <TheSnide> i'll review any patch :) 19:00:31 <TheSnide> so, putting them in branch would be awesome 19:00:54 <GrumpyFux> OK 19:01:47 <GrumpyFux> I'd like to ask for your special attention for #1394. If accepted, this should even go into a Debian point release 19:01:53 * TheSnide tends to abuse github's pullreq feature as a todo. 19:02:56 <GrumpyFux> More about bugs? 19:03:25 <TheSnide> sur 19:03:26 <TheSnide> e 19:03:35 <GrumpyFux> then discuss 19:04:03 <TheSnide> i'll take a look at that one, 19:07:38 <GrumpyFux> (/me is at a terribly noisy place, so I'd like to push a bit) 19:10:46 <GrumpyFux> So, I'd mention three projects I have in mind. Two of them I'd just start, these are: 19:11:10 <TheSnide> btw, /me is using helmut's way for bugfixes. 19:11:35 <GrumpyFux> - rewrite all plugins to use the "dirtyconfig" feature whenever possible. This should speed up data acquisition over slow links 19:12:18 <TheSnide> start a branch for each fix the earliest possible, then merge them on a common bugfix branch. that way each commit can still be merged individually where needed. 19:13:09 <TheSnide> for dirtyconfig, Flameeye1 also started fusing some plugins together via multigraph 19:13:39 <TheSnide> so, both optimizations could be done quite easily where applicable. 19:13:48 <GrumpyFux> Don't get the full idea behind that branching but this might be due to local circumstances. We'll discuss that another time 19:13:57 <GrumpyFux> - Second project, do a major rework on the handling of multigraph. There are issues that really make me frown, but changes might break some plugins 19:13:58 <TheSnide> so, +1 (in case it wasnt obvious) 19:14:44 <TheSnide> i think the most valid issue is the leading _. 19:15:18 <TheSnide> that all pure numeric field gets squashed away to "_" is quite annoying. 19:15:33 <GrumpyFux> There's a ticket about that :-> 19:15:40 <TheSnide> i know. 19:15:54 <TheSnide> might even be yours... 19:16:01 <GrumpyFux> It is 19:16:06 <TheSnide> :D 19:16:37 <TheSnide> but changing any protocol, even slighly, is 3.0 material to me. 19:17:00 <GrumpyFux> The last thing might require more discussion. So, just the idea: Have munin-graph and munin-cgi-graph running under the same user-id (that would probably be www-data). Same for html 19:17:03 <TheSnide> _adding_ isnt, _changing_ is. 19:17:33 <TheSnide> for uid, there's a lot more to say. 19:20:08 <TheSnide> as, i'd like a separate uid of m-node, m-a and munin master 19:20:25 <GrumpyFux> OK, part of a bigger architectural change 19:20:31 <TheSnide> yep. 19:20:50 <TheSnide> not earlier than 3.0 anwyay. 19:21:06 <GrumpyFux> Point, I'm interested in that one since it would ease hybrid mode (#1393) 19:22:13 <TheSnide> GrumpyFux: could you craft a wiki/branch/whatever thing that brings some particular bugs on my radar ? 19:22:48 * TheSnide is currenlty rushing to finish sql before end of year :) 19:22:53 * GrumpyFux takes a mental note 19:23:22 <TheSnide> thx 19:24:01 <TheSnide> anything else ? 19:24:22 <TheSnide> (anyone) 19:25:18 <TheSnide> end meeting in 5 min timeout otherwise 19:25:33 <GrumpyFux> nothing here 19:27:24 <TheSnide> thx all. 19:27:27 <TheSnide> #endmeeting