19:25:53 <TheSnide> #startmeeting
19:25:53 <MeetBot> Meeting started Wed Apr  8 19:25:53 2015 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:25:53 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:25:57 <TheSnide> hi all
19:26:10 <TheSnide> (ok a little early)
19:26:17 <ssm> 'ello
19:29:28 <hugin> [13munin] 15darac opened pull request #428: Topic carbon (06devel...06topic-carbon) 02http://git.io/veM7a
19:33:46 <TheSnide> ssm: hi!
19:34:02 <TheSnide> #topic devel
19:34:43 <TheSnide> so, this week was quite busy, with chteuchteu doing so many awesome PR that we had to grant him push :-D
19:35:08 <ssm> "The reward for a job well done is another job"
19:35:21 <TheSnide> the new httpd also got some real testing, and several bugs were opened
19:36:23 <TheSnide> I'm planning to address most of them this week.
19:36:29 <TheSnide> anyway..
19:36:31 <TheSnide> #topic UI
19:36:37 <chteuchteu> Hi! I'm glad I finally had a development environment up and running :) I'm glad I'm helpful, and would like to thank you again for all your help and including me to the team! :)
19:36:59 <TheSnide> The UI is now vastly responsive
19:37:40 <TheSnide> some tweaks are stil needed, but it has the "wow" factor that I was searching for a new major release.
19:37:57 <chteuchteu> (and its far to be finished yet ;))
19:39:10 <TheSnide> also, thx to ssm the dev env is also much more easy to setup.
19:40:06 <TheSnide> (there are also still some issues on OSX, but these should be handled easily)
19:40:38 <TheSnide> the greenish theme has a nice refreshing look.
19:40:41 <ssm> any outstanding wishes for the dev environment could be filed to the github issue tracker, I'll tag them with "dev environment"
19:41:17 <TheSnide> ssm: yeah. that's also something i'd like to hilite. GH issues are now used, much more than TRAC were.
19:42:22 <TheSnide> mostly due to the friction-less experience GH has. The fact that IRC notifications are enabled for most of the events makes it very efficient to work with.
19:42:53 <TheSnide> #info do *not* hesitate to abuse the GH issue/PR system. As it's very easy to triage them.
19:43:20 <TheSnide> #topic bugs
19:44:00 <TheSnide> i don't know the status of the integration of deb BTS with GH hosted projects, but I guess it's quite easy to setup.
19:44:43 <TheSnide> 2.1.12 is nearing soon, ideally next week.
19:44:48 <ssm> TheSnide: it already exists.  A debian BTS issue can be marked with the URL for the github issue, and when the github issue changes, the debian issue does as well
19:44:58 <TheSnide> k, perfect.
19:45:03 * ssm has something for bugs, too…
19:45:09 <ssm> when you're done :)
19:45:45 <TheSnide> ssm: bah, the meeting is mostly a BoF, feel free to interrupt anytime. As it's not like verbal thing where it blurs the message
19:46:23 <ssm> We have a number of bugs marked "need design decision" at https://github.com/munin-monitoring/munin/labels/todo%3A%20needs%20design%20decision, I would like a design decision on some of them :)
19:46:24 <TheSnide> so, any bugs/issues/feature not ready next meeting will be in .13.
19:46:39 <TheSnide> #topic grooming
19:46:45 <ssm> I'll make a 2.1.13 milestone for bugs to move to
19:47:12 <ssm> …and done
19:48:25 <ssm> grooming?
19:48:30 <TheSnide> like scrum :D
19:48:40 <chteuchteu> :)
19:48:41 <TheSnide> we just have our vStandup
19:48:58 <kjetilho> putting make-up on the pig before release
19:49:06 <chteuchteu> So as said, I mainly worked on design (that's what you can see)
19:49:15 <kjetilho> (sorry :)
19:49:30 <ssm> kjetilho: :P
19:49:34 <TheSnide> kjetilho: *heavy* makeup, usually. and some silicone. lots of silicone.
19:49:45 <chteuchteu> I also cleaned the templates (quickly): mostly reindent, but also cleaned it to be more HTML5-ish :)
19:50:18 <chteuchteu> There may be some more cleanings to do, but this can wait
19:50:36 <chteuchteu> We also wanted to add some dynamism to the pages, that's easily done with JS without any other dependency
19:50:54 <chteuchteu> As you may have seen, there is now (since this afternoon ;) ) a global filter field on each page.
19:50:55 <TheSnide> #204 is waiting for an option to enable/disable.
19:51:02 <TheSnide> (night & day)
19:51:30 <chteuchteu> Each page will handle this differently (filter plugins / graphs / ...)
19:51:39 <chteuchteu> There are some more enhancements, but those are the biggest ones :)
19:51:58 <chteuchteu> So as a summary: design, user experience, code cleaning, JS dynamism :)
19:52:29 <ssm> TheSnide: 204 needs a configuration file option and a default in M::C::Defaults?
19:52:34 <chteuchteu> Since I'm quite new on the project, I don't really know what is where: ssm's refactor (moving web-related stuff to /web dir) helped :)
19:52:49 <hugin> [13munin] 15steveschnepp comment on issue #204: This needs a option to enable/disable it. Bonus would be to be able to specify the ranges, as it is currently very CET centric.... 02http://git.io/veMj1
19:53:18 <TheSnide> ssm: as a minimum, yes. adding it unconditionnaly seems a bad idea.
19:53:55 <ssm> TheSnide: I agree.  I'll remove the "need design decision", and replace it with "not finished yet" on that issue. :)
19:54:19 <TheSnide> for #311 (unknowns), i _really_ don't know how to do it.
19:54:26 <hugin> [13munin] 15ssm comment on issue #204: Add a default in Munin::Common::Defaults, and a configuration option to enable it. 02http://git.io/veDeu
19:54:50 <TheSnide> it's not even that i don't how to implement. i just don't know _what_ to implement ...
19:55:10 <ssm> :)
19:55:37 <TheSnide> ... maybe have a gradual implementation. never remove anything, and have a greyish outline ?
19:56:03 <TheSnide> then have a "button", "cli command", whatever to manually prune things.
19:56:15 <ssm> I need to wade through the configuration parser for other things anyway.  I can add the option and config to that pull request.
19:56:32 <ssm> if that's ok?
19:56:45 <TheSnide> #204 ?
19:56:47 <ssm> yes
19:56:51 <TheSnide> +1
19:57:16 <TheSnide> (ok to me)
19:57:32 <ssm> assigned it to moi
19:58:01 <ssm> #363, hammer out a perltidy, and then use it to tidy all the things!!!one
19:59:12 <hugin> [13munin] 15steveschnepp opened issue #429: ui: show the problematic graphs with some kind of *overlayed* color 02http://git.io/veDJU
19:59:45 <TheSnide> #311 is related to just created #429, which is UI.
20:00:40 <TheSnide> 1rst step resolution of #311 is to provide persistnace to everything, but give some hint to the UI via a specific attribute.
20:01:07 <TheSnide> how we manually prune the things can be postponed.
20:01:51 <TheSnide> i agree with the solution proposed in #347
20:01:53 <ssm> "grey out" as in "show graphs where the data is old, coloured gray"?
20:02:24 <TheSnide> i was thinking of a CSS transparent grey overlayed DIV.
20:02:33 <TheSnide> /translucent/
20:02:51 <hugin> [13munin] 15ssm comment on issue #347: :+1:  02http://git.io/veDUx
20:02:56 <TheSnide> but yes, visual effect will be that, dimming the graph.
20:03:11 <chteuchteu> Are removed plugins still shown in the web pages?
20:03:16 <ssm> ok, removed label from 347
20:03:58 <TheSnide> #363 is also ok. let's go ahead on that, and iterate if needed.
20:04:16 <TheSnide> -> just don't mass-tidy yet.
20:04:22 <ssm> ok :)
20:04:49 <TheSnide> #376 needs to think about it outside the meeting.
20:05:04 <TheSnide> #action TheSnide has to complete #376 for next meeting.
20:05:33 <TheSnide> #421 is a bug. the feature has to come back. period.
20:06:08 <TheSnide> ... as chteuchteu will/has already implement filtering via javascript.
20:06:09 <ssm> #428 just arrived, and it would possibly scale better to have a graphite agent run munin-asyncd on each node.
20:06:32 <ssm> to send data at short intervals from munin node to $elsewhere
20:06:33 <TheSnide> and for that last one, you know my PoV
20:07:05 <TheSnide> i'm in favor of any fork/spinoff/whatever :)
20:07:34 <TheSnide> --> i just don't want to offer any support
20:08:09 <TheSnide> i'd say it's much easy right now to have the master pushing things to carbon."
20:09:08 <TheSnide> having the node pushing things is on the roadmap, but i had to lower its prio, since i prefer to have a rock solid fundation prior to deeply change our architecture
20:10:34 <TheSnide> besides, i'm planning to rewrite the munin-update part, and it should support multiple independant connection *per plugin*.
20:10:51 <ssm> Seems like a quick win, but it could be done as a "munin-limits" which push all data somewhere, instead of in the perl module.
20:11:19 <ssm> but instead of munin-limits, it would send all data somewhere.  It looks _really_ easy to implement that way.
20:11:23 <TheSnide> i mean, the work queue unit will be service-itemized instead of the current node-itemization
20:12:07 <TheSnide> munin-limits still relies storable. it also has to be rewritten.
20:12:20 <ssm> good point.  It should run from sqlite
20:12:34 <TheSnide> --> and i was planning to directly integrate limits computation inside update.
20:12:58 <TheSnide> as it feels a waste to parse the whole install again and again.
20:12:59 <ssm> just add a perl module for that, and tell munin-update to use it :)
20:13:02 <ssm> yes
20:13:07 <TheSnide> yup.
20:13:50 <TheSnide> i'll externalize the RRD update also, so it could be put in another workqueue to be sent to external systems.
20:14:10 <ssm> as for #428, I'd like to reimplement it differently, but having a good way to send a copy of all data $elsewhere is good.
20:14:27 <TheSnide> be it "email alert, like munin-limit did, or the raw numbers to something else"
20:14:31 <ssm> like http://mojolicio.us/perldoc/Minion for Mojolicious…
20:14:50 <TheSnide> yeah, that one.
20:15:22 <TheSnide> hmm.... i guess we'll go the mojo way soonish if you keep insisting :D
20:16:03 <TheSnide> does it supports multi-cpu ?
20:16:28 <TheSnide> --> i had the impression that mojo was singlethreaded. 'event loop, but 1 thread"
20:17:29 <ssm> you can run it as a preforked set, or single.  Each mojolicious uses event loop.  You can run many minions
20:17:36 <TheSnide> hmmm.. minion looks like it does. but i don't want to repeat the fastcgi hell :D
20:18:04 <ssm> http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#DEPLOYMENT - Mojolicious in Hypnotoad runs multiple worker processes
20:18:31 <TheSnide> ssm: could you have a close look at it, and evaluate the gain/loss ?
20:19:14 <TheSnide> #action TheSnide will make a list of components with their characteritics
20:19:50 <TheSnide> #action ssm will match them to the mojo world, in order to see if it's a good idea to bite the bullet or not.
20:19:51 <ssm> I've got a Mojolicious app running under Hypnotoad in production, it's been running for a year or two.
20:20:04 <ssm> any faults with it is due to my own programming :)
20:20:37 <TheSnide> ssm: i just force-delegated you :D
20:20:45 <ssm> ack
20:21:20 <TheSnide> it's just to know the estimated cost of each component. if you have some mojo knowledge it's easy. (i don't)
20:21:34 * TheSnide lacks mojo.
20:22:24 * ssm arranged the MojoConf in Oslo last 2014 with a few others.  Got training ,too, which must have been good, since I paid for it :P
20:22:42 <TheSnide> hhehe
20:22:43 <ssm> s/last//
20:23:05 <TheSnide> last 2014... so many of them ! :D
20:23:33 * ssm wants a tardis
20:23:44 <TheSnide> too blue.
20:23:58 <TheSnide> but it's efficient for zipping.
20:25:03 <TheSnide> 60 open issues left. let's triage them prior next meeting
20:25:37 <TheSnide> #action TheSnide will triage the 60 open issue for next meeting. that way we will groom them efficently.
20:25:50 <ssm> good plan
20:25:53 <chteuchteu> +1!
20:26:03 <TheSnide> #topic misc
20:26:23 <TheSnide> free flow of questions/rants/jokes
20:27:00 <chteuchteu> A blind man goes into a bar. Then into a chair. Then into a table.
20:27:05 <TheSnide> (about the mojo stuff, remember my test box is a Rpi1 :D)
20:27:15 <chteuchteu> OK, this joke is lame too in french.
20:27:24 <chteuchteu> TheSnide: what about a RPi2? :D
20:27:25 <TheSnide> nice :D
20:27:48 <TheSnide> chteuchteu: #1 i don't have one. #2 the purpose of the rpi1 is that it is slow :-D
20:28:09 <TheSnide> rpi1 is the 2015 definition of "slow".
20:28:24 <chteuchteu> :
20:28:29 <chteuchteu> Yes indeed :D
20:28:44 <TheSnide> "if it runs on a r1, it runs everywhere".
20:29:07 <TheSnide> ... as you can take it everywhere in your pocket o_O
20:29:27 <ssm> git is 10 years old :) https://www.atlassian.com/git/articles/10-years-of-git/
20:29:43 <TheSnide> ssm: munin still wins :D
20:30:02 <TheSnide> (wishful thinking)
20:30:20 <ssm> I'm not going to dig for the pre-svn verson control history…
20:30:49 <TheSnide> about git... i'd be glad that systemd would have the same fate than bitkeeper
20:30:56 <chteuchteu> What was before SVN?
20:31:01 <ssm> CVS
20:31:14 <ssm> tig
20:31:17 <TheSnide> and before RCS, and before RCCS
20:31:26 <TheSnide> and before all that, cp.
20:31:29 <TheSnide> :D
20:31:31 <chteuchteu> :D
20:31:50 <ssm> 2004-01-02 15:18  Automatic Commit  New repository initialized by cvs2svn.
20:31:55 <ssm> from the git repo…
20:33:12 <TheSnide> ... i don't find the url for a funny article about using "cp" as a enhanced git
20:35:01 <be0rn> Mmmm, cvs
20:37:32 <TheSnide> http://lilypondblog.org/2014/06/what-you-miss-with-version-control/
20:37:51 <TheSnide> and http://thedailywtf.com/articles/The_Best-est_Version_Control :-D
20:38:04 <TheSnide> so. nothing to add ?
20:38:26 <chteuchteu> Nothing for me :)
20:38:35 <TheSnide> (just pasted the 2 prior link above the end, to have them logged.
20:38:42 <ssm> first RPM package of munin (then LRRD)  Tue Jun 18 2002 Kjetil Torgrim Homme <kjetilho@linpro.no> \n new package
20:39:00 <TheSnide> LinproRRD ?
20:39:03 <ssm> es
20:39:05 <ssm> yes
20:40:04 <chteuchteu> Birthday is soon then :P
20:40:32 <ssm> yup.
20:41:05 <TheSnide> 23 this year
20:41:22 <TheSnide> hmmm.
20:41:40 <TheSnide> 13
20:41:48 <TheSnide> (too tired, cannot compute).
20:41:51 <TheSnide> #endmeeting