19:34:00 <sumpfralle> #startmeeting
19:34:00 <MeetBot> Meeting started Wed Jun 13 19:34:00 2018 UTC.  The chair is sumpfralle. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:34:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:34:20 <sumpfralle> #chair TheSnide h01ger chteuchteu be0rn
19:34:20 <MeetBot> Current chairs: TheSnide be0rn chteuchteu h01ger sumpfralle
19:34:26 <sumpfralle> welcome!
19:35:30 <TheSnide> hi
19:35:45 <TheSnide> sumpfralle: don't worry... usually it's me who's terribly late
19:35:53 <sumpfralle> I noticed :)
19:36:03 <sumpfralle> what are you doing around that time? (I am curious)
19:36:03 <TheSnide> o_O
19:36:19 <TheSnide> meeting with US west coast.
19:36:25 <sumpfralle> at work?
19:36:30 <TheSnide> home
19:36:46 <sumpfralle> late evenings :(
19:36:48 <sumpfralle> ok - topics?
19:37:04 <TheSnide> #topic 2.999.x
19:37:11 <sumpfralle> yeah!
19:37:30 <TheSnide> Well, one may have noticed, but i resumed working on the 2.999 branch
19:37:47 <TheSnide> slowly, but surely
19:37:54 <sumpfralle> it was noticed with excitement :)
19:38:29 <sumpfralle> how is your feeling for its current state?
19:38:29 <TheSnide> So, some good and some bad parts
19:39:04 <TheSnide> good: i didn't have any clue about the code i did before. And I managed to enter it quite swiftly.
19:39:46 <TheSnide> so, for that it's quite a success. And I even discovered several core flaws that I clearly overlooked before
19:41:00 <TheSnide> the not-so-good is that it takes a little while. As to be honest, I do expect something around 70-80% of rewrite of the master code.
19:41:16 <sumpfralle> due to the database storage?
19:41:22 <sumpfralle> or what are the main topics?
19:41:23 <TheSnide> the only thing that remains the same is the Config parsing & the Node parsing
19:41:32 <TheSnide> yeah.
19:41:50 <TheSnide> DB storage is a fundamental shift
19:42:16 <sumpfralle> when I took a look at the code, I had a bit of difficulty to grasp the traversing of nested data - is this also part of the "maybe to be rewriten code"?
19:42:19 <sumpfralle> (just curious)
19:42:31 * sumpfralle felt his brain hurting a bit at that time
19:42:35 <TheSnide> -> this is good since it clearly shows the datastructures in a "documented" form, which is quickly queriable
19:42:48 <sumpfralle> yes
19:43:20 <TheSnide> Now, i basically throwed away most of the datastructures
19:43:46 <TheSnide> since it was always a little hellish to "deserialize" in one's mind.
19:43:51 <sumpfralle> I have the feeling, this is a good approach.
19:43:54 <sumpfralle> yes
19:44:13 <TheSnide> it is. definelty. I was hopeful before, but now I'm even certain.
19:44:55 <TheSnide> I also thow away all the tests (sorry for ssm who wrote them). Because basically the code isn't there anymore
19:44:55 <sumpfralle> So the outbound interface (config & rrd) remains - the internals are changing. Right?
19:45:31 <TheSnide> I was planning to have a look at the coverage for some E2E scenarios, and throw away code that isn't covered : means it's not used :D
19:45:42 <sumpfralle> E2E?
19:45:48 <TheSnide> end-2-end sorry
19:45:57 <sumpfralle> ah - good
19:46:14 <TheSnide> and, yes. I'm aiming for 100% backwards compatiiblity
19:46:30 <TheSnide> .. on the RRD + nodes level
19:46:39 <sumpfralle> (I do not have hard feelings for that - just curious)
19:46:51 <TheSnide> upgrading will just be a matter of ... upgrading.
19:46:58 * sumpfralle is not convinced, that rrd is the future to go in the long term
19:47:02 <TheSnide> at least for 1.X & 2.0 ones.
19:47:07 <sumpfralle> good
19:47:32 <TheSnide> for the poor souls that are in 2.1 & 2.999, life might be a little more difficult
19:47:42 <sumpfralle> :)
19:47:50 <sumpfralle> there are only few of them!
19:47:51 <TheSnide> .. but not much more than "rm -Rf /var/lib/munin/datafile*"
19:47:55 <sumpfralle> good
19:48:10 <TheSnide> so, on the bad side of things:
19:48:36 <TheSnide> - quite a number of things are missing. Much more than I thought of when I stopped.
19:49:15 <TheSnide> it's also due to the fact that now I implemented a "persistent" DB. One that isn't thrown away each run.
19:49:29 <TheSnide> --> this is possible with the SQL move.
19:50:22 <TheSnide> ... and paves the way for non-cron-driven updates. More towards a "node events push" like pattern. But that'll be 4.0. Let's focus on 3.0 :D
19:50:31 <sumpfralle> :)
19:50:55 <TheSnide> more closely, it does enable a pgsql storage.
19:51:14 <TheSnide> since sqlite has serious concurrency issues.
19:51:21 <sumpfralle> yes :(
19:51:33 <TheSnide> --> well, less "concurrency issues" than "scaling issues"
19:52:05 <TheSnide> as, SQLite works perfectly well in a multithread context. But it does lock like hell, and therefore we don't benefit much.
19:52:23 <sumpfralle> yes
19:52:32 <TheSnide> but it really shines on a small to medium install.
19:52:40 <TheSnide> so, it'll be the default.
19:52:59 <sumpfralle> good
19:53:07 <TheSnide> also, the whole SQL layer is currently very naive
19:53:26 <sumpfralle> in other words: internal details are spread around the code?
19:53:32 <TheSnide> i basically only use prepared statement caching as optim. And that's it.
19:54:17 <TheSnide> sumpfralle: well, i don't really want to write an abstraction layer. As I think that direct access to SQL is efficient enough.
19:54:38 <TheSnide> not only in terms of perf, but also in terms of code clarity.
19:55:16 <TheSnide> so, "details" are indeed spread out. But that's a feature, as i do *not* plan to change the DB structure anytime soon.
19:55:25 <sumpfralle> abstraction: I was just thinking of "get_latest_alarm"-style functions instead of SQL queries
19:55:47 * sumpfralle has a different taste - but this is fine
19:55:47 <TheSnide> oh, well.. it's *somewhat* abstracted away.
19:56:12 <sumpfralle> ok
19:56:33 <TheSnide> but i admit it's quite loosely done. I just use the "anonymous block" + comment
19:56:42 <TheSnide> much more than a proper function call
19:56:52 <TheSnide> specially if it's only called in 1 place.
19:57:24 <sumpfralle> taste differs :)
19:57:25 <TheSnide> --> Perl is notoriously bad at calling functions.... and so is my brain. I like to read core like a book. Not like a wiki: )
19:57:49 <TheSnide> but, yeah.. I'm super duper old school in that matter
19:58:21 <sumpfralle> this increases the burden placed on you a bit :(
19:58:23 <TheSnide> Perl is bad at calling function. And calling methods is even some magnitude worse.
19:58:40 <TheSnide> anyway.
19:59:06 <TheSnide> so, the move to persistent db had a nasty side effect :
19:59:21 <TheSnide> - things are only *added* now. nothing is ever removed
19:59:33 <sumpfralle> database entries?
19:59:36 <TheSnide> - this is nice to show old stuff
19:59:42 <TheSnide> but gets in the way :)
20:00:05 <sumpfralle> we just need to release the garbage collecting version soon enough :)
20:00:23 <TheSnide> http://demo.munin-monitoring.org/munin-monitoring.org/demo.munin-monitoring.org/uptime-day.png?t=1528919953919
20:00:44 <TheSnide> It was buggy for a day or so, and did the parsing wrong.
20:00:57 <TheSnide> but the fields stay now forever.
20:01:21 <TheSnide> ... only in the graphs, that is. So when the fix is issues all the graph will automatically be right again.
20:01:24 <sumpfralle> this is a good thing!
20:01:55 <TheSnide> so, a fix is in progress, have to test it later
20:02:30 <TheSnide> another bad thing: dirtygraph is disabled.
20:02:46 <TheSnide> I have to see if the recent fixes for lucas made it work. It might.
20:02:47 <sumpfralle> we are hoping with you for its survival :)
20:03:29 <TheSnide> #topic testing
20:03:55 <TheSnide> well... this one really bothers me. I like to write tests. But I don't like to struggle to write a test framework. :)
20:04:26 <TheSnide> the bootstrap is quite slower than expected. And I do *not* want to rely on Mock.
20:04:42 <sumpfralle> Mock is a popular perl testing framework?
20:04:48 <TheSnide> Mocking feels so wrong
20:04:59 <TheSnide> no, the Mocking pattern.
20:05:01 <sumpfralle> ok
20:05:12 <TheSnide> many fmk do exist in Perl.. as elsewhere
20:05:48 <TheSnide> the only things i'd like to mock are:
20:05:50 <TheSnide> - the config
20:06:01 <TheSnide> - the node
20:06:10 <TheSnide> - the http call
20:06:32 <TheSnide> else than that, i'd rather have it fully "integrated"
20:07:13 <TheSnide> And i'd like to be able to write tests with:
20:07:17 <TheSnide> - a config
20:07:25 <TheSnide> - a node output
20:07:58 <TheSnide> and then check the ouput of the httpd server against several urls.
20:08:31 <TheSnide> that would make my refactoring much much more easier. As it will be just a matter of "no test shall fail"
20:09:02 <TheSnide> i mean, the moment you need to rewrite a single line of testing code when refactoring you lost.
20:10:11 <TheSnide> anyway... I'm much more focusing on real, manual (myself), testing and closing the feature gap than that testing framework
20:10:30 <sumpfralle> ok
20:10:34 <TheSnide> (it isn't that scalable in the long run... but who cares)
20:10:52 <sumpfralle> in this case (no tests being added right now): shouldn't we leave the existing tests there for the moment?
20:11:02 <sumpfralle> (or are they focussed on internals?)
20:11:07 <TheSnide> if we don't close the feature gap, noone will even care to have a 100% test coverage :)
20:11:27 <TheSnide> fact is, they are very well written, but more unit tests.
20:11:34 <sumpfralle> I do not want to question the approach in general.
20:11:34 <TheSnide> therefore not very useful right now.
20:11:52 <TheSnide> i do plan to revert the commit that removes them
20:12:11 <sumpfralle> personally I would probably remove them piecewise, as soon as they break (and I realize the are not useful anymore)
20:12:31 <sumpfralle> most projects get abandoned on their way to the last magic big rewrite :)
20:12:36 <TheSnide> bah, i always like the big hammer approach... and i'm quite lazy :)
20:13:08 <TheSnide> sumpfralle: did you read recent code ?
20:13:13 <TheSnide> (or at least my changesets)
20:13:18 <sumpfralle> no, sorry
20:13:33 * sumpfralle will do so in the next days
20:13:36 <TheSnide> it would be very interesting to see if you can understand than
20:13:40 <TheSnide> them*
20:13:56 <sumpfralle> good, I am curious too, if my python-brain will enjoy it :)
20:14:01 <TheSnide> as, you'll need a very small knowledge of Perl... I write Perl like C with regexes :)
20:14:23 <sumpfralle> this leaves room for a milling coding styles :)
20:14:30 <sumpfralle> "million"
20:15:18 <TheSnide> anyway, tell me.
20:15:21 <sumpfralle> I will
20:15:36 <TheSnide> As, if you don't understand a piece of code, it qualifies as a bug.
20:15:47 <sumpfralle> It feels good to see that you have a plan and that you enjoy!
20:15:49 <TheSnide> and i have to:
20:15:51 <sumpfralle> :)
20:15:54 <TheSnide> - refactor
20:15:55 <TheSnide> - comment
20:16:01 <TheSnide> or even both :)
20:16:06 <sumpfralle> yeah - I love commented functions :)
20:16:37 <TheSnide> my devs tell me that i have a 5-yo coding style.
20:16:47 <sumpfralle> is that good or bad?
20:16:49 <TheSnide> (not the 5y experince... 5y age)
20:17:12 <sumpfralle> this *could* be "it is readable" :)
20:17:14 <TheSnide> sumpfralle: dunno... i think it's good, since everyone loves to hack into my code :)
20:17:38 <TheSnide> but they despise my coding rules...
20:18:08 <sumpfralle> btw: is perlcritic or someone applicable for us?
20:18:11 <sumpfralle> (usable)
20:18:12 <TheSnide> sumpfralle: it is readable. I mean, i spend 20x more time reading it than writing it
20:18:19 <sumpfralle> I am a fan of python's linting tools.
20:18:20 <TheSnide> dunno
20:18:27 <TheSnide> but why not
20:19:00 <sumpfralle> so I will try to check it against your new code and maybe add a bit of travis tests for it (where applicable)
20:19:26 * TheSnide is also a big fan of "-Wall -pedantic", so...
20:19:32 <sumpfralle> great!
20:19:44 <TheSnide> yeah, "they despise my coding rules"
20:20:24 <TheSnide> #topic packaging
20:20:41 <TheSnide> well.. seems debian pkg is back from oblivion
20:20:58 <sumpfralle> it was always well maintained, or?
20:21:09 <TheSnide> wondering about the init scripts that were dubious in 2.999.7
20:21:16 <sumpfralle> dubious?
20:21:18 <TheSnide> well, as well as upstream
20:21:37 <TheSnide> dubious= not working automatiically
20:21:56 <TheSnide> i added a systemd service sample for httpd
20:22:00 <sumpfralle> less tested due to systemd, I guess
20:22:23 <TheSnide> oh, "init script" == whatever is needed to start it automatically.
20:22:32 <TheSnide> no tech implied
20:22:43 <sumpfralle> I think, the systemd part of the 2.999 package was fine
20:23:03 <TheSnide> I also removed the rrdcached part
20:23:24 <sumpfralle> should it be optional again?
20:23:26 <TheSnide> IMHO, it should be picked from the environement
20:23:27 <sumpfralle> (not run by default)
20:23:29 <sumpfralle> ok
20:23:34 <TheSnide> not from the config file
20:23:41 <sumpfralle> ?
20:23:52 <sumpfralle> so you would not like to ship an rrd service/init file?
20:23:54 <TheSnide> there's a rrdcached_address in the sample config
20:24:18 <TheSnide> no, i don't mind shipping a rrd service
20:24:28 <TheSnide> ideally in its own package
20:24:31 <TheSnide> if possible
20:24:52 <sumpfralle> ah: "config" -> configuration file; "environment" -> "environment variable"?
20:24:55 <TheSnide> if env driven, rrd does fallback automatically in case the socket is not present
20:25:14 <TheSnide> if config, well... the rrd call just fails
20:25:28 <sumpfralle> I understand - we do not need to deal with it at all
20:25:28 <TheSnide> oh, yes. sorry (conf/env-
20:25:46 <sumpfralle> good
20:26:14 <sumpfralle> that makes it easier to package the optional bonus-service rrdcached
20:26:15 <TheSnide> can we source a /etc/default/munin in a systemd service file ?
20:26:22 <sumpfralle> yes, this is common
20:26:44 <TheSnide> well, do your magic.
20:27:00 <TheSnide> but I think i'll just deprecate the rrdcached config line.
20:27:23 <sumpfralle> sounds good - just documenting the integration is sufficient
20:27:32 <TheSnide> (by plainly ignoring it, and emit a warning instead)
20:27:39 <sumpfralle> good
20:27:59 <TheSnide> ... it was useful before since we had CGI... but now we have our very own httpd daemon.
20:28:21 <sumpfralle> which is a good step forward, I think
20:28:33 <TheSnide> indeed.
20:28:36 <sumpfralle> less hassle with webserver configurations
20:28:52 <TheSnide> that said: i do *not* plan to support HTTPS
20:29:15 <TheSnide> if one wants https, he just have to put a https layer on front
20:29:25 <sumpfralle> yes
20:29:27 <TheSnide> like varnish.
20:29:28 <sumpfralle> absolutely
20:29:54 <TheSnide> That said, i'd like to be able to serve all our content from sockets.
20:29:59 <TheSnide> httpd+node
20:31:04 <TheSnide> ... that said, the other distro are pretty much dead.
20:31:10 <TheSnide> (munin-wise)
20:31:30 <sumpfralle> yes, at the moment
20:31:46 * TheSnide doesn't really care about anything beyond debian, for the matter
20:31:58 <sumpfralle> if I remember correctly, two people volunteered to have a look at the fedora packaging?
20:32:11 <TheSnide> yep. that would be great.
20:32:20 <TheSnide> but i won't bother with that myself
20:32:33 <sumpfralle> we just need to make munin interesting and shiny again - then they will follow :)
20:32:40 <TheSnide> ;)
20:32:54 <TheSnide> #topic future plans
20:33:05 <TheSnide> replacing RRD isn't that easy.
20:33:19 * sumpfralle was just thinking aloud - no action is intended
20:33:21 <TheSnide> as we don't really abstract it away.
20:33:27 <sumpfralle> yes
20:33:31 <TheSnide> specially the CDEF part
20:33:50 <sumpfralle> we have an almost complete parser, I think :)
20:34:02 * sumpfralle did not indent to delve into this topic too much
20:34:02 <TheSnide> I would be interested in having the timeseries stored into pgsql also... but
20:34:29 <TheSnide> I don't want to reimplement anything that RRD offers
20:34:30 <sumpfralle> "intent" (but do not stop, if you are interested)
20:34:36 <sumpfralle> yes, I agree
20:35:04 <TheSnide> i saw some time ago that rrd can leverage a libdbi.c storage.
20:35:04 <sumpfralle> supporting another (optional) storage would be something nice
20:35:10 <TheSnide> instead of files.
20:35:11 <sumpfralle> but absolutely not important right now
20:35:24 <TheSnide> wonders if that's interesting
20:35:58 <TheSnide> ... yeah, rrd if very much fine for me. Specially since we can emit JSON & XML now instead of PNG.
20:36:11 <sumpfralle> yes, this is nice
20:36:16 <lucas> as a munin user, I think that it's current positioning in the monitoring marketplace is good, and that it should not try to become something else such as prometheus, influxdb, etc.
20:36:41 <TheSnide> lucas: that's also my red line
20:36:45 * sumpfralle has a similar feeling
20:37:08 <TheSnide> my red line is "it just works"...
20:37:35 <sumpfralle> and writing plugins is (almost) a pleasure
20:37:43 <TheSnide> which is ... quite challenging those days on every growing installs
20:37:43 <lucas> munin clearly doesn't work for every need, but it works very well for a lot of needs, even if it's not the needs that gather a lot of hype currently
20:38:21 <TheSnide> lucas: it is often installed as a "monitoring backup system"
20:38:49 <TheSnide> I think its strong points are :
20:39:03 <TheSnide> - braindead easy to install & operate
20:39:25 <TheSnide> - plugin writing is so sweet, it makes you addicted
20:40:00 <TheSnide> - very low impact on the node
20:40:25 <TheSnide> and, those... i'd like to keep it that way.
20:40:38 * sumpfralle agrees
20:40:50 <lucas> right, totally agreed
20:41:01 <TheSnide> Now, i just want to have a nicer UI (which chteuchteu made) and scaling (which I'm in progress)
20:41:50 <TheSnide> we lost the hype battle long time ago, when Perl lost it :D
20:42:29 <sumpfralle> regarding the UI: I *could* (vaguely) live with the thought of using an external software for visualizing munin's data.
20:42:35 <sumpfralle> perl - yes, what a pity (halfway)
20:42:38 * TheSnide is trying to become as venerable as apache-httpd.
20:42:44 <lucas> :)
20:43:18 <TheSnide> i mean, apache is old, sortof slow. But still mature & quite used a lot.
20:43:35 <TheSnide> ok.. EOF for me
20:44:42 <sumpfralle> that was a good long session!
20:45:21 <TheSnide> thx sumpfralle & lucas
20:45:46 <sumpfralle> thanks to you for sharing your innermost thoughts about munin :)
20:45:57 <TheSnide> :p
20:46:08 <sumpfralle> have a good week!
20:46:33 <sumpfralle> #endmeeting