17:58:40 <TheSnide> #startmeeting
17:58:40 <MeetBot> Meeting started Tue Jan  7 17:58:40 2014 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:40 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:47 <TheSnide> hi all
18:01:29 <TheSnide> so, this meeting might be short
18:01:46 <TheSnide> #topic 2.2
18:02:00 <TheSnide> nothing happened since last time.
18:03:33 <TheSnide> #info 2.1.4 _can_ be packaged, and should be. Just not forced upon unwary users. As, it would deb/exp-like distro only.
18:05:10 <TheSnide> So far the reception has being good, but noone looked at it further than the ChangeLog :)
18:05:39 <TheSnide> #topic munin-c
18:09:18 <TheSnide> GrumpyFux mentioned that IO-starved hosts might miss some polls
18:09:45 * TheSnide also noticed that cpu-starved one also do.
18:11:01 <TheSnide> helmut mentioned memlockd to avoid putting munin-c components outside filecache. It isnt possible easily with regular munin-node.
18:11:18 <TheSnide> ... but it would fit munin-c well IMHO.
18:12:23 <TheSnide> #topic next meetings
18:12:35 <GrumpyFux> TheSnide: Yeah, but I think that's basically  Linux problem. We _could_ put the time-critical munin processes into realtime I/O classes and the like, but that's just patchwork
18:13:01 <TheSnide> #topic starved nodes
18:13:26 <TheSnide> GrumpyFux: would that work ?
18:13:54 <GrumpyFux> Haven't tried much
18:14:03 <TheSnide> GrumpyFux: ... as it seems linux is broken by design for now.
18:14:09 <TheSnide> (on that topic)
18:15:15 <GrumpyFux> Yes, but that is old breakage. It just became more obvious.
18:15:26 <TheSnide> GrumpyFux: note that a deadline iosched might help, but doesnt fit my "minimal interference"
18:15:29 <GrumpyFux> Was a funny idea to try out, say, BSD kernel
18:16:06 <TheSnide> i had the recall that bsd are better io-wise, and linux cpu-wise.
18:16:26 <TheSnide> ... but that's ancient sayings.
18:16:46 <TheSnide> dunno if it is still true.
18:17:38 <TheSnide> anyway, i think the "heavily loaded" node is worth to explore.
18:18:10 <TheSnide> as, it's usually at that moment you need munin the most.
18:19:52 <GrumpyFux> I think we should ask a Linux kernel wizard about that.
18:20:20 <TheSnide> ... that's also why i'm rewriting the apache plugin to read the scoteboard without http
18:20:46 <GrumpyFux> Whatever munin(-node) could do, it must not be too intrusive. And the issue might have been resolved by the kernel devs in the next months anyway
18:20:59 <TheSnide> yep, it isnt something magic
18:21:15 <TheSnide> k
18:22:20 <TheSnide> but i do not want to rely on recent kernels, as nodes are usually old
18:22:47 <GrumpyFux> What munin could do anyway was to reduce I/O load of gathering. So munin-c might help a lot.
18:22:55 <TheSnide> perf on master is other issye
18:23:00 <GrumpyFux> While here-documents in bash-scripts are worst
18:23:09 <TheSnide> yup
18:23:57 <helmut> imo, munin should reduce on io-load itself
18:24:30 <helmut> if it were to produce less io, the stalls would be shorter
18:24:52 <GrumpyFux> Keep things sorted, we're mostly talking about the node, right?
18:25:41 <helmut> even the node produces noticeable io peaks
18:26:37 <TheSnide> GrumpyFux: so says the topic, yes :)
18:27:17 <TheSnide> but i agree that nodes do sometimes do quite some IO.
18:27:48 <TheSnide> yet I dont think we'll solve it outside munin-c.
18:28:31 <TheSnide> aka, i do not want to spend time on the perl version of munin-node for perf improvements.
18:28:32 <GrumpyFux> There are a lot of non-standard plugins out there
18:28:49 <GrumpyFux> So that might end up in "munin plugin authoring guidelines"
18:29:11 <TheSnide> (the plugins themselves, i'm not so categoric. specially the core ones.)
18:29:28 <GrumpyFux> And another solution might be magic in the master to learn about slow plugins and to handle them in a second connection
18:29:35 <TheSnide> GrumpyFux: yeah, that would be a nice addition.
18:29:56 <helmut> what happend to my imap-like asynchronous proposal?
18:30:05 <helmut> that would supersede any issues with slow plugins
18:30:44 <GrumpyFux> Not sure it would
18:33:05 <TheSnide> helmut: i'm thinking about it for my m-u rewrite.
18:33:08 <GrumpyFux> But changes in the munin protocol ist something I'd really prefer to discuss on the next munin WWDC
18:33:27 <TheSnide> GrumpyFux: +1
18:35:48 <TheSnide> helmut: i think it is great idea. just NotNow :)
18:38:35 <GrumpyFux> So, what's next on the agenda?
18:40:21 <TheSnide> #topic next meetings
18:40:52 <TheSnide> it was suggested to start the meeting a little later
18:41:25 <TheSnide> I proposed 2030 IIRC
18:42:18 <TheSnide> any others ?
18:44:01 <GrumpyFux> <-- in favour
18:47:59 * helmut is heading to bed now. :-p
18:48:17 <TheSnide> #action TheSnide will setup a poll for next meeting times
18:48:58 <TheSnide> #topic miniDebConf
18:49:47 <GrumpyFux> There'll be a talk about munin?
18:50:06 <TheSnide> dont think so.
18:50:23 <TheSnide> i didnt register any slot, so i think i'll too late.
18:51:15 <pretec> Maybe a lightning talk?
18:51:19 <TheSnide> besides, i wont have much new to say
18:51:39 <TheSnide> i'd like a AMA sessio n :)
18:52:24 <TheSnide> I'll be there on Sat, starting from 1500.
18:52:41 <TheSnide> ... until end-of-day :)
18:52:55 <GrumpyFux> Not sure if I can make it, have to resolve some issues
18:52:57 <TheSnide> whatever time that is.
18:53:49 <TheSnide> pretec: coming ?
18:53:56 <TheSnide> (i suppose no)
18:54:40 <pretec> No, but i will go to the FOSDEM two (?) weeks later
18:54:54 <TheSnide> pretec: hmmmf, now you say so :/
18:56:30 <TheSnide> anyway. will try to see if I can organize an informal meeting. Even with an IRC part.
18:57:13 <TheSnide> #action TheSnide will orga a AMA sessions. details to be defined outside meeting.
18:57:32 <TheSnide> ok
18:57:35 <TheSnide> #topic misc
19:00:32 <TheSnide> ok
19:00:37 <TheSnide> #endmeeting