19:31:31 <TheSnide> #startmeeting
19:31:31 <MeetBot> Meeting started Wed Apr 15 19:31:31 2015 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:31:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:31:53 <TheSnide> #topic bugs grooming
19:32:53 <ssm> any bugs in need of grooming?
19:33:51 <chteuchteu> Yup!
19:33:52 * ssm just found a 8 cm hairy spider on the home office wall.  It's a bug, and almost big enough to groom.
19:34:08 <chteuchteu> When using munin-httpd, plugins names still aren't showing
19:34:20 <chteuchteu> That's actually annoying, especially when I want to test some design :D
19:34:33 <TheSnide> for #376, i propose that only oss plugin are in core
19:34:51 <TheSnide> chteuchteu: i fixed some
19:35:12 <chteuchteu> When? I think that I didn't pulled those modifs then
19:35:45 <TheSnide> #action TheSnide and chteuchteu will work togeter after meeting to solve that plugin name bug
19:35:52 <chteuchteu> +1
19:36:07 <TheSnide> #topic plugins grooming (376)
19:36:23 <ssm> TheSnide: Plugins that actually monitor open source software in core, check
19:36:44 <TheSnide> for java, i'd like to have a generic jmx plugin in core
19:37:05 <ssm> resurrect the java builder, then
19:37:34 <TheSnide> we can put it in antoher git repo if it's better to maitniant
19:37:43 <Blueking> there exist plugin for intel pstate (cpuspeed) ?
19:38:02 <ssm> I think that it would be easier to maintain a jmx-plugin repo
19:38:35 <TheSnide> ssm: ok for seperate repo.
19:39:12 <TheSnide> i'd still like to have it as "core", as in the tgz
19:39:37 <TheSnide> but it might be overkill... as we advocate packaged versions anyway :)
19:41:46 <TheSnide> anyway, perl+shell would be nice.
19:41:54 <TheSnide> (for core ones)
19:41:57 <ssm> I'll start by putting it in its own repo, and see how to best distribute it
19:42:33 <TheSnide> i think we still has the venerable diskstat in python
19:42:55 <ssm> https://github.com/munin-monitoring/munin/search?l=python
19:43:41 <TheSnide> i guess py is ok, no need to rush for a replacement.
19:43:42 <ssm> ipmi_sensor_ and smart_ plugins in python, as well as something in the "contrib" folder.
19:45:32 <TheSnide> having an actual _use_ for them would be nice also
19:46:01 <ssm> everything not monitoring OSS will be relocated to the contrib repo.  Anything in the contrib repo which makes sense to include in core?
19:46:28 <Blueking> this zoom thing works ?
19:46:38 <TheSnide> ... thing is, i'm really divided between having "munin comes with 64k plugins ready to use" and "munin if full of old and buggy plugins"
19:46:52 <TheSnide> Blueking: it doe.
19:47:22 <Blueking> not here
19:47:38 <TheSnide> _adding_ plugins to core sill needs 2 commiters.
19:47:47 <ssm> TheSnide: it helps if we have a set of criteria for inclusion in core.  "monitoring Open Source Software", "Implemented in sh or perl", "autoconf", "bug free-ish", "clean code", anything else?
19:48:00 <ssm> "actually useful"
19:48:10 <TheSnide> unless a commiters is _the_ author, and plans to maintain it;
19:48:31 <ssm> that, too.  It takes commitment, and not just a commit
19:48:54 * TheSnide did puts most of his personal plugins in contrib.
19:49:18 <ssm> a tool to include plugins from contrib may be better than including lots of plugins in core?
19:49:21 <ssm> include and update
19:49:39 <TheSnide> definitely.
19:49:43 <ssm> ack
19:49:56 <chteuchteu> That would actually be awesome indeed
19:50:19 <chteuchteu> So we could limit the plugins list officially included in code, but allow users to _easily_ install plugins from contrib
19:50:31 <ssm> yes
19:50:59 <TheSnide> ssm: let that *tool* be git-based to avoid recoding too many things. and restorting to a plain "git update for sync", and "grep" for searching
19:51:30 <TheSnide> ssm: it would be the best of all worlds.
19:51:58 <ssm> munin-node-configure needs to look in both the "core" path and the "contrib" path, which is the main change, I think.  The rest is a "git pull" or update
19:52:37 <TheSnide> ssm: i'm still thinking about having a "munin" APT repo of debianized contrib plugins. (and a YUM repo if we find a volunteer)
19:53:15 <TheSnide> ssm: i'll change it to be able to specify multiple time the --plugindir
19:53:47 <TheSnide> so, it can even look at 3214 paths if you're so inclined.
19:54:12 <ssm> yes
19:54:17 <TheSnide> ... the keyword is *in order*. First takes precedence if the pluginname is the same.
19:54:33 <TheSnide> or last one ? to be overridable
19:55:00 <TheSnide> a-la $PATH
19:55:53 <TheSnide> munin-node might also take multiple plugin dirs, but i'm not that eager to. as currently it's very easy to see the configured plugins.
19:55:57 <ssm> as long as munin-node-configure can use multiple source paths.  Having a $MUNIN_PLUGIN_PATH or a configuration option would both work
19:56:20 <TheSnide> : separated ?
19:56:22 <ssm> …or a commandline switch
19:56:27 <TheSnide> pure unix style ?
19:56:45 <ssm> if the variable says somethingPATH, it would make sense to split on ":"
19:57:12 <TheSnide> yup, that's why i proposed
19:57:13 <ssm> http://en.wikipedia.org/wiki/Principle_of_least_astonishment
19:57:32 <TheSnide> +1 then
19:57:36 <ssm> +1
19:58:04 <TheSnide> #action TheSnide will add a way to have multiple source paths for munin-node-configure
19:58:21 <ssm> that would require no changes for munin-node, which is nice
19:58:53 <TheSnide> yup. having all plugins in 1 dir is nice. 3AM-style ops wise.
19:59:07 <TheSnide> (plugin symlinks)
20:00:28 <TheSnide> ssm: can you try to hack something about m-get ?
20:00:47 <TheSnide> (hint, try to mimic apt-get like cli)
20:01:00 <ssm> munin-get moo?
20:02:11 <TheSnide> munin-get m0 :)
20:02:13 <TheSnide> munin-get mm0 :)
20:02:18 <chteuchteu> munin-get update && munin-get install multicpu1sec?
20:02:35 <TheSnide> chteuchteu: basically the idea, yes.
20:02:40 <ssm> . o O { how hard could it be? }
20:03:22 <TheSnide> install = grep + ln -s
20:03:35 <ssm> "update = git clone or pull"
20:04:10 <TheSnide> clean  == rm -Rf ?
20:04:11 <TheSnide> :D
20:05:01 <TheSnide> hint, make the whole git r/o, it would prevent "clever" users to "tweak" it.
20:05:29 <TheSnide> --> dedicated user  'munin-get' ?
20:06:05 <ssm> with config-template per plugin.  Aahhhh, feature creep :D
20:06:08 <TheSnide> it could later evolve in a "tweak the plugin locally", then push a PR to github :-D
20:06:25 <TheSnide> let's have "clean, update & install" for now.
20:07:22 <ssm> restart munin-node on changes…
20:07:32 <TheSnide> as support should state : if broken, just do "munin-get clean && munin-get update && munin-get install"
20:07:52 <TheSnide> via dbus ? /me takes the exit.
20:08:13 <ssm> be careful what you ask for, you may just get it
20:08:31 <TheSnide> i know. munin-get reload ?
20:08:53 <TheSnide> "service ... restart" would be ok methinks
20:09:11 <ssm> design => new ticket
20:09:18 <ssm> in the interest in keeping a short meeting :)
20:09:35 <TheSnide> #action TheSnide will open a new ticket on munin-get
20:10:39 <TheSnide> https://github.com/munin-monitoring/munin/issues/296 is interesting
20:11:08 <Blueking> how long are meeting going on ?
20:11:31 <ssm> until we've got nothing else to talk about, or the internet runs out of power :)
20:11:42 <ssm> usually an hour or so
20:11:43 <chteuchteu> (usually the 2nd one) ;P
20:12:09 <TheSnide> that said, i don't have much more to say
20:12:20 <chteuchteu> BTW, since we're talking about legends: I redesigned the legend table to include field type definition on hover in order to be able to remove the definitions page
20:12:39 <TheSnide> how does it work on touch device ?
20:12:59 <TheSnide> #topic munin ui
20:13:31 <chteuchteu> About the UI: I'm still working on general improvements :) These are details now, but still important.
20:13:53 <chteuchteu> We still have to fix some issues, such as relative links (navigation menu on the left, header, dynazoom links)
20:14:06 <chteuchteu> These are the "urgent" things.
20:14:35 <TheSnide> #action TheSnide has to find a way to publish the devel branch with chteuchteu's work. ideally daily.
20:14:48 <chteuchteu> That would be great :)
20:14:57 <chteuchteu> We also talked (outside of meetings) about some cool features like grids (user would be able to mix heterogeneous graphs in one grid to allow better comparisons)
20:15:09 <chteuchteu> But that could wait until we fix some more urgent issues :)
20:15:16 <TheSnide> yup
20:15:47 <TheSnide> chteuchteu: i think i'll install some daily build of httpd on dmmO
20:15:48 <chteuchteu> As always, if you have any improvements ideas / bugfixes to report, don't hesitate to open issues or comment open ones :)
20:15:58 <chteuchteu> That would be awesome :)
20:16:19 <TheSnide> ssm, any ETA on 2.1.11-1 ?
20:17:24 <ssm> I've not worked on the packaging since last time. Most of my spare time is spent on studies for the next month or so.
20:17:48 <TheSnide> :D
20:20:22 <ssm> I'm almost done, though.  Hopefully there should be some good news next meeting regarding .debs
20:21:00 <ssm> (note the vague and indirect language :)
20:23:57 <TheSnide> :)
20:25:35 <TheSnide> ok.
20:25:40 <TheSnide> #endmeeting