17:01:28 #startmeeting 17:01:28 Meeting started Tue Oct 8 17:01:28 2013 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:33 hi 17:02:23 #info agenda is 2.2, munin-c, etc. 17:02:33 #topic 2.2 17:02:54 nothing really new here. 17:03:50 we have to decide if i should continue in the sql branch, or just merge in devel 17:04:31 devel feels more lively, but it *will* be broken from time to time 17:04:54 and the eventual upgrades wont be easy. 17:05:27 but it enables 2.1.x to have early sql feats 17:05:48 (the more i think about it, the more i do like it) 17:06:11 ... anyway, i said that 2.1.x is _unstable_. 17:08:24 if noone objects, i'll make it an agreement :) 17:08:55 well... 17:08:56 question, sql will be the way to go? 17:09:04 yes. 17:09:05 Or is it still rather proof-of-concept? 17:09:16 nope, it will replace datafiles. 17:09:46 code is *way* easier to write. 17:09:49 So, even if it should break with a big boom, you'll rather fix than revert? 17:10:12 it wont. (i hope). but yes, i'll fixit. 17:10:50 and at the moment sql isn't obviously broken? 17:10:54 did anyone tried m 17:10:55 ? 17:11:13 well, i changed the sql schema several times already. 17:11:41 i cannot say it wont change anymore. but as it is a sqlite db for now, it feels like datafiles. 17:11:43 But in a way, that's short-term cache-like data anyway? 17:12:08 just initial acces is much faster. 17:12:28 no need to load the *whole* data in ram prior to use. 17:12:51 after access is slower, but not that slower. 17:12:53 Anyway, I feel inclined to: Bring it to a bigger audience, 2.1 is declared unstable, so better see the booms early 17:13:01 sounds like a huge win in any case 17:13:27 GrumpyFux: that's my rationale 17:13:28 (evil plan to abuse sql will follow) 17:13:37 are all the datafiles being converted to sql? how backend-specific is the sql code? 17:13:56 (i.e. can we switch out to $real_dbms if we want to?) 17:13:59 olasd: for what i've seen currently, yes. i just have to rewrite most of the code. 17:14:13 olasd: but it's not a bad thing per se. 17:14:43 olasd: Unless I'm mistaken, you could delete datafiles any time now anyway (unless munin is just running) 17:14:46 olasd: currently it recreates a whole new db each run. 17:15:18 I see 17:15:25 olasd: 2.2 wont have real sql backend i'm afraid. 17:15:42 as i dont want to rewrite the whole m-u. 17:15:45 not for 2.2 17:15:56 i will do. but later. 17:16:07 urgent matter is cgi for now. 17:16:18 well, if it allows setups with a few hundred nodes without the "I'm loading a multi-hundred-megabyte datafile" overhead, it's a win 17:16:21 specifically html. 17:17:02 500 nodes overview currently has a 300ms response time. in plain CGI mode. 17:17:20 yeah, that's "a bit" better :p 17:17:23 on a 2GHz Xenon 17:17:34 Xeon. 17:17:35 :D 17:17:48 (from 2k9 era) 17:18:25 IMO, considering the time it took, you have ironed most of the kinks out of the SQL stuff 17:18:39 if the DB is recreated on every run, I don't see where the upgrade issue is? 17:19:30 (or rather, might be) 17:19:34 old data, for derive limits. 17:19:41 but it's very marginal. 17:19:46 oh, right 17:20:02 (so you fetch some data before wiping the db?) 17:20:07 and "thou shall not twiddle munin's internals" 17:20:44 as, a sqlite db has more connectors than a perl storable :) 17:21:35 "if you have issues in stuff you built from it, i'll just laugh evily" 17:21:53 (not really, but you get the mood) 17:22:26 olasd: but anyway. it's a huge win. period. 17:22:53 right 17:23:11 olasd: and no, most of the time spent was doing things that failed miserably. 17:23:18 *pat pat* 17:24:29 olasd: but now i think i found out a way to make it work nicely 17:25:06 even much less code than previous iterations :) 17:26:23 so, i'll just mergw it in devel regularly. agreed ? 17:26:49 * TheSnide casts a quick vote 17:26:52 +1 17:27:40 .... 17:28:44 #agreed sql branch will be merged regularly in devel and rreleased as 2.1 17:28:57 well I'm in favor, more exposure means more incentive for quick fixes :p 17:29:19 #topic munin c 17:30:17 pretec started to work on the .deb 17:31:24 TheSnide, have docs? if so, i can start the rpm's .. 17:32:39 there's several readme 17:33:00 i see 3 licenses, and a one-line readme. 17:34:11 inside the src/* 17:34:16 wait. make that two licenses, and a readme. the readme says gpl2, but the git repo has gpl2 and 3 17:34:43 pretec also noticed the license hell 17:35:00 either one is fine with me tbh, just needs to be consistent 17:36:40 and ftr, i already have rpms .. they are really just waiting on docs so a user can actually use it. 17:43:46 munin-c is designed to be a dropin 17:44:19 only for the node, it has to be called from inetd, and that should be package driven. 17:44:26 (inetd conf) 17:45:37 ... but i'll write some manpages, using POD 17:51:05 #action TheSnide has to write some manpages 17:51:42 #info fenris02 has rpms that waits for some polish and docs. 17:52:11 fenris02: we agreed to split in 2 binary packages. 17:52:20 node + plugins 18:01:19 #topic else 18:01:32 any topic ? 18:05:20 bugs? #1382 went rrd upstream, Tobi has promised to pick my patch+enhancement 18:06:51 nice 18:07:42 And I'd be glad if an SNMP wizard could browse through the related tickets I've created 18:08:11 you shall ask nicolai, he's quite fluent in snmp 18:08:33 (janl) 18:09:48 * TheSnide doesnt look much @ bugs lately. 18:10:33 We should do some kind of BSP ... there are way too many at the moment 18:12:32 And I hate to look into "Hm, that's interesting" tickets, just to find I filed them 18:14:24 ohh. meeting. hi :) 18:16:12 helmut: meeting is mostly closing itself :) 18:16:12 followup remark to munin-c: the code base has diverged in consistency since the recent moves. moving it around and bolting autotools onto it has not helped. we should clean that up. 18:16:58 GrumpyFux: i won't have time for a BSP, so i cannot advocate one :-/ 18:17:44 Let's do a munin WWDC for that 18:18:14 if you think that it helps, I can step in as maintainer for munin-c and review all branches/patches for errors, consistency and legalese. 18:24:19 I need to train my C skill anyway. ;-) 18:24:47 helmut: please do. 18:25:10 #topic munin c 18:25:13 TheSnide: that'd imply that the canonical location for munin-c.git is one that I can write to. any ideas? 18:25:34 #info helmut proposed "I can step in as maintainer for munin-c and review all branches/patches for errors, consistency and legalese." 18:25:56 helmut: you *do* have a github account :) 18:26:29 ---> https://github.com/helmutg 18:27:22 helmut: but, the canonical location for munin-c is like the other official git : git.munin-monitoring.org 18:27:25 I failed to delete it, so I stopped using it, because I can no longer abide by the tos 18:28:02 --verbose (after the meeting) 18:28:03 helmut: git@git.munin-monitoring.org:munin-c.git 18:28:40 #action TheSnide will give push access to helmut on g.mm0 for munin-c 18:28:56 helmut: let's sort it out after the meeting 18:29:01 TheSnide: ack. I'll drop you a mail after the meeting 18:30:30 #topic else 18:32:30 GrumpyFux: would it be interesting to have an irc hacking meeting ? 18:32:58 Meaning precisely? 18:33:33 GrumpyFux: doing munin hacking all together at a fixed time. 18:34:02 GrumpyFux: with IRC as a shared communication medium 18:34:19 I have no experience with that 18:35:11 #action TheSnide will orga a small munin IrcHackFest to see if there's some interested ppl 18:37:59 ok, anything else ? 18:40:35 #endmeeting