19:36:46 <TheSnide> #startmeeting
19:36:46 <MeetBot> Meeting started Wed Jan 28 19:36:46 2015 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:36:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:36:49 <TheSnide> hi all!
19:37:30 <thor77> hi
19:42:03 <TheSnide> #topic CGI
19:42:38 <TheSnide> so, i finally bite the bullet, and transformed the CGI in a pure httpd serve.
19:43:17 <TheSnide> it's a huge success so far, as it ease a lot dev & configuration.
19:48:18 <TheSnide> ... and it's even about 4x faster on my test box
19:50:19 <TheSnide> #info cgi will be *removed* in 2.1.11 and replaced by munin-httpd
19:53:56 <thor77> #agreed
19:54:00 <thor77> like it
19:54:09 <thor77> never got that cgi running :D
19:59:32 <TheSnide> as usual, cron code will be replaced by a wrapper aeound the on-demand one.
20:00:03 <TheSnide> ... multi-process is even planned !
20:00:34 <TheSnide> i'm looking at also integrating munin-update kn httpd via POST
20:02:54 <thor77> :)
20:03:10 <thor77> sounds very nice
20:10:58 <TheSnide> that means having a single multiple-facet process, which can have some nasty side-effects.
20:11:19 <TheSnide> --> such as if under heavy GET load, one might miss some POST.
20:11:28 <TheSnide> ... which is bad IMHO
20:12:46 <TheSnide> so, i still have some work on my hands, but basically, i won't look back.
20:13:53 <TheSnide> ... also i looked at threading instead of multiprocessing, for munin-httpd, it would enable a really nice queing code. IPC is still possible, yet a little more complciated.
20:14:46 <TheSnide> (note that i'm not a huge fan of threading. I do prefer single-threaded, multiple-processes. It is usually way easier to debug)
20:17:41 <TheSnide> also, I'm thinking about making munin-node listen on a UNIX socket instead of a TCP one. And have asyncd do its job.
20:17:59 <TheSnide> #topic self-scheduling node
20:19:22 <TheSnide> async and node are here to be merged. maybe not code-wise, but async should have the possiblity to launch node by itself. That would limit the need of a root-owned TCP listening socket.
20:20:18 <TheSnide> which, these days, seems a bad idea. We actually have a very good track record of CVE. But that might just indicate that they were not found yet.
20:21:38 <TheSnide> Every CVE we had involved managing to put a malicious plugin. No full-remote exploit is known.
20:22:43 <TheSnide> i have to add async to munin-c, and finalize munin-c features to be on part with the stock one. And have it replaced.
20:25:55 <TheSnide> ... Note that's afraid that i have to change the spooldir protocol a little, to enable safe access over a networked-fs.
20:27:01 <TheSnide> ---> supported network-fs are "nfs, cifs, rsync, scp & ftp".
20:27:36 <TheSnide> this is to enable a remote syncing without direct ssh access.
20:29:04 <TheSnide> ... also it enables a win32 munin-node-c to spool its files locally that can be read by a munin-update if the munin server has that drive mounted via cifs.
20:29:35 <TheSnide> #topic win32
20:29:49 <TheSnide> i really want to suport win32. for the node.
20:30:37 <TheSnide> ... for the master i still think it's a little far, but removing the CGI requirement & thinking about a possible multithreading makes it really closer.
20:31:06 <TheSnide> ideally, munin-c will be portable, and therefore used everywhere.
20:31:16 <TheSnide> #topic osx
20:31:58 <TheSnide> I started to write an homebrew formula. It won't target 2.0, but 2.1+
20:32:25 <TheSnide> there will be 2 formulas : master and munin-c.
20:33:12 <TheSnide> the issue about munin-c is the lack of plugins on anything else than linux. That said we can reuse the stock plugins for a while
20:33:53 <TheSnide> #topic version numbering
20:34:23 <TheSnide> #info Next stable will be Munin 3.0. (no 2.2 will happen)
20:36:17 <TheSnide> It was mainly motivated by the removal of CGI. Then everything became possible :D
20:37:21 <TheSnide> #info a 1.2 node polling is still fully supported by a 3.0 master. Failures to do so qualifies as a bug that will be fixed.
20:38:16 <TheSnide> as usual, polling a 3.0 node will *mostly* work with a 2.0 master, provided you don't use advanced features.
20:39:00 <TheSnide> #topic misc
20:39:12 <TheSnide> ... ok that's it for today.
20:39:26 <TheSnide> Any questions ? (feel free to ask me anything)
20:39:36 <chteuchteu> Wow, quite exciting! :D (I don't have any question)
20:40:27 <TheSnide> oh, and chteuchteu is our new recruit. He's our UI guy, and you might already know him via Munin4Android.
20:40:39 <chteuchteu> Yes indeed :) Sorry I came late
20:41:01 <chteuchteu> I introduced myself last week but I don't know if everyone knows me
20:41:09 <TheSnide> chteuchteu: no worries. we are _very_ async here. That's why everything in a meeting is logged.
20:41:24 <chteuchteu> I'll mainly work on UI (HTML, CSS, JS), and am currently working on the dynazoom page
20:42:04 <chteuchteu> And yep, I'm the main dev of Munin for Android :)
20:43:54 <TheSnide> oh, and about the spring cleaning, i also removed munin-api, which was quite short-lived, as it's replaced by the html part. Just change the extension to access the Model that generates the HTML page, in JSON or XML format.
20:44:48 <TheSnide> the code is less clean, but at i don't like duplicated features, and i don't have time to maintain both.
20:45:08 <chteuchteu> Good idea! (I'm actually saying this because I'll easier to implement on Munin for Android :D)
20:45:09 <TheSnide> the /output/ is less clean.
20:45:35 <TheSnide> ... well that's it for me.
20:46:10 <TheSnide> (auto-closing meeting in 15 min, unless there is some activity)
20:59:09 <TheSnide> #endmeeting