19:36:33 <TheSnide> #startmeeting
19:36:33 <MeetBot> Meeting started Wed Apr 29 19:36:33 2015 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:36:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:36:52 <TheSnide> hi all :)
19:37:02 <chteuchteu> Hi ;)
19:37:21 <TheSnide> so, nothing much on my side, so i'll let others talk
19:37:49 <chteuchteu> For me it's (as it has been in the last few weeks), some misc enhancements on UI
19:38:25 <chteuchteu> I've spotted some issues (and opened ones on GitHub): I don't necessarily have the competences to fix those yet, so that's why they still may be open
19:38:35 <m-r-b> <penk@freenode> hihi.
19:39:10 <chteuchteu> As always, please don't hesitate to pull the changes and give your opinion on changes :)
19:40:25 <m-r-b> <penk@freenode> i was invited in because i'd like to contribute fixes to some plugins that are... crunchy and difficult to configure.  specifically i'm working on the tomcat one.  i was able to get it running but only after much coding / debugging / hacking / working.  i assume just fork plugins/ in github, mod, and pull request, but is there a doc describing 'best practices' for error conditions?
19:40:49 <TheSnide> errors for plugins ?
19:41:00 <m-r-b> <penk@freenode> ie, if the plugin is getting an auth error getting status from tomcat, how should that be reported?   right now, i was getting  name.value 0
19:41:01 <m-r-b> <penk@freenode> and nothing else
19:41:04 <m-r-b> <penk@freenode> er
19:41:05 <m-r-b> <penk@freenode> name.value U
19:41:08 <chteuchteu> BTW, I volunteer to test this tomcat plugin once it will be stable :) What does it monitor?
19:41:12 <TheSnide> i'd say a really good intro would be to write some plugin doc :)
19:41:24 <m-r-b> <penk@freenode> i'm okay with that, but i didn't want to step on previous work.
19:41:36 <TheSnide> about the tomcat one, i really like to have a generic jmx one in core.
19:41:43 <m-r-b> <penk@freenode> cht: it's just modifying the existing tomcat plugins for jvm, accesses, etc.  it's really easy to break / misconfigure it :(
19:41:50 <TheSnide> much more than a tomcat specific one.
19:41:59 <be0rn> A plugin with problems should report a) when executed by munin-node-configure and b) in munin-node.log
19:42:03 <m-r-b> <penk@freenode> a JMX plugin would be tasty.
19:42:22 <m-r-b> <penk@freenode> be0rn: nothing on stderr or stdout when run with munin-run ?
19:42:25 * TheSnide has some design specs for a jmx pluing in his head
19:42:44 <be0rn> STDERR with munin-run would be very useful
19:42:46 <m-r-b> <penk@freenode> thesnide: would be happy to work with you on them.  right now i just want to clean up / debug the existing one to get my fingers int he pie.
19:42:49 <TheSnide> errors should go to stdout, prefixed via #
19:42:55 <be0rn> ...or that
19:43:00 <m-r-b> <penk@freenode> see,here's where things go wonky :)
19:43:10 <TheSnide> and then exit != 0
19:43:17 <m-r-b> <penk@freenode> so, do we have  aplugin guideline doc or should i draft one?
19:43:22 <be0rn> Listen to TheSnide, he's at the helm
19:43:25 <chteuchteu> I think there's one
19:43:30 <m-r-b> <penk@freenode> thesnide: GUIDE US LEADER DESLOK.
19:43:35 <chteuchteu> I know I read something about this this week
19:44:25 <TheSnide> http://guide.munin-monitoring.org/en/latest/plugin/writing.html
19:44:32 <chteuchteu> http://munin-monitoring.org/wiki/HowToWritePlugins
19:44:38 <m-r-b> <penk@freenode> heh
19:44:43 <chteuchteu> For my link, Ctrl+F Error handling
19:45:13 <m-r-b> <penk@freenode> mmm, shoudln't these be merged?
19:45:46 <TheSnide> yup, wiki pages should move/migrate to the guide, which is rst+git
19:46:04 <m-r-b> <penk@freenode> those two pages do not match on how errors should be handled :(
19:46:17 <TheSnide> there's also some adjustements to be made.
19:46:17 <m-r-b> <penk@freenode> oh hmm. maybe they're not.
19:46:27 <m-r-b> <penk@freenode> If the munin plugin emits errors, they will be visible in /var/log/munin/munin-node.log
19:46:40 <TheSnide> ... as the wiki page are quite old, and some time did pass with some feedback from the field
19:46:41 <m-r-b> <penk@freenode> if that's run via the cron, yes, that would be the case.  but if munin-run runs it, it'll come on stderr.
19:46:55 <m-r-b> <penk@freenode> i'd be happy to modify the guide page.
19:47:16 <m-r-b> <penk@freenode> since that should be canonical, yes?
19:47:23 <TheSnide> #action penk will maintain the plugin guide pages
19:47:32 <TheSnide> looks like you just volunteered :DD
19:47:37 <m-r-b> <penk@freenode> i'm good with that.
19:47:49 <m-r-b> <penk@freenode> am i blessed with Powers?  my github name is 'shevett'
19:48:03 <chteuchteu> (you can't go back now, TheSnide #actioned it ;P)
19:48:04 <TheSnide> penk, just use the PR mechanism. it's very easi
19:48:10 <TheSnide> y
19:48:15 <m-r-b> <penk@freenode> okie dokey.
19:48:30 <m-r-b> <penk@freenode> ahh i see.
19:48:33 <TheSnide> and some nice things might come after a while :D
19:48:45 <m-r-b> <penk@freenode> doc/plugin/writing.rst
19:48:59 <m-r-b> <penk@freenode> i'll do that.  i'll also submit changes to make the tomcat plugins adhere to what i'm writring, and put a pull request in for that too.
19:49:04 <TheSnide> yup, to know which file, just use the "edit on github" link
19:49:10 <TheSnide> yup
19:50:44 <TheSnide> if you're not used to RST, just look at the existing files, or some docs is also at http://sphinx-doc.org
19:50:53 <m-r-b> <penk@freenode> nah, its cool.  i'll figure it out.
19:51:29 <m-r-b> <penk@freenode> the short version is 'If you're writing a plugin, errors / config issues / etc should go to stderr.  when run as munin-run you'lkl see them as the console during debugging.  if an error is thrown while run via cron, it'll show in munin-node.log."
19:51:32 <m-r-b> <penk@freenode> that's pretty straightforward.
19:51:40 <TheSnide> yup.
19:52:04 <TheSnide> and don't forget to exit != 0
19:52:24 <m-r-b> <penk@freenode> yepyep.
19:53:06 <TheSnide> then, coupled with some plugin automatic documentation, and autoconfig makes it nice to use plugins
19:53:28 <TheSnide> specially, the "header" part with documents the env vars to use
19:53:37 <m-r-b> <penk@freenode> yep.  the probelm is the tomcat plugins have absolutely zero error handling.  if -anything- is wrong, it just puts out a U.
19:54:06 <TheSnide> well, that's also a strategy.
19:54:13 <m-r-b> <penk@freenode> a poor one :)
19:54:18 <TheSnide> just makes it quite hard to debug
19:55:06 * TheSnide will write some rfc for his ideal generic jmx plugin
19:55:17 <TheSnide> #action TheSnide will write some rfc for his ideal generic jmx plugin
19:55:49 <TheSnide> i think it'll be a java-based one.
19:56:32 <m-r-b> <penk@freenode> mmm.
19:56:39 <m-r-b> <penk@freenode> not sure if a java based plugin makes the most sense.
19:56:46 <m-r-b> <penk@freenode> startup/teardown of the JVM for each query is clunky.
19:57:56 <chteuchteu> +1
20:06:49 <m-r-b> <penk@freenode> got quiet :)  #meetingover?
20:21:03 <chteuchteu> #meetingover
20:21:06 <chteuchteu> (I tried)
20:28:38 <TheSnide> got disco, sorry
20:29:11 <TheSnide> startup/teardown of the JVM can be limited to 1, thanks to multigraph and dirtyconfig
20:29:45 <TheSnide> also, i don't want to rewrite a JMX parser in something else than a JVM.
20:31:10 <TheSnide> #endmeeting