19:28:21 <sumpfralle1> #startmeeting
19:28:21 <MeetBot> Meeting started Wed Jun 27 19:28:21 2018 UTC.  The chair is sumpfralle1. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:28:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:28:43 <sumpfralle1> #chair TheSnide chteuchteu h01ger kenyon be0rn
19:28:43 <MeetBot> Current chairs: TheSnide be0rn chteuchteu h01ger kenyon sumpfralle1
19:29:05 <sumpfralle1> welcome!
19:37:02 <sumpfralle1> human presences are welcome to raise their voice :)
19:37:22 * sumpfralle1 will talk to himself otherwise ...
19:38:19 <TheSnide> hi
19:38:39 <sumpfralle1> hello!
19:39:08 <sumpfralle1> do you have a specific topic? Otherwise I would just summarize what I did during the last week
19:39:40 <TheSnide> go ahead, i'll follow with my small achievements.
19:39:56 <sumpfralle1> hehe - there is no order of relevance implied :)
19:40:20 <sumpfralle1> I did more Debian packaging.
19:40:33 <sumpfralle1> The package for 2.0 looks nice, now (for my taste).
19:40:57 <sumpfralle1> h01ger is not available right now, thus it will wait for a few more days until it can see the light
19:41:23 <sumpfralle1> And I am right now adding a bit of tests: only for the packaging (systemd services, config files, ...)
19:41:37 <sumpfralle1> (as part of Debian's autopkgtest)
19:41:57 <sumpfralle1> and I did a bit more of cleanup in the issue tracker
19:42:02 <sumpfralle1> that's it
19:43:11 <sumpfralle1> meanwhile many small changes landed in stable-2.0 - maybe we want to relase it?
19:46:56 <TheSnide> sure
19:47:08 <TheSnide> i'm not really looking at the 2.0.x to be honest
19:47:33 * TheSnide is more focused on pushing 3.0 out of the door
19:48:11 <sumpfralle1> a very good strategy!
19:48:12 <TheSnide> so, just tell me a commit ID, and i'll just release it.
19:48:40 <TheSnide> acutally, I think you can even "git tag -s" yourself. I'll use that to do the tgz
19:49:05 <TheSnide> #topic 2.999.x
19:49:20 <TheSnide> So, i did some work on that branch lately.
19:49:21 <sumpfralle1> OK - good. In one or two days I am done with Debian testing. I will tell you then. (and tag it before)
19:49:25 <TheSnide> what works now:
19:49:52 <TheSnide> - sqlite/pgsql is fully working. You can choose via /etc/munin.conf
19:50:40 <TheSnide> - new test is also working. It's a full E2E test case. It only does smoke test for now, not testing the failures.
19:51:29 <TheSnide> - fixed a *huge* bug that prevented graph with "negative" to be generated 90% of the cases.
19:51:50 <sumpfralle1> yeah!
19:52:33 <TheSnide> Therefore i released 2.999.9, since I was quite happy with the current state
19:53:08 * sumpfralle1 cheers
19:53:21 <TheSnide> a huge topic are "limits". This is in an unknown state
19:53:29 <TheSnide> (pun intended)
19:53:56 <sumpfralle1> :)
19:54:01 <TheSnide> So, i'll have to rewrite that part.
19:54:31 <TheSnide> -> I'm planning to *generate* the limits directly in munin-update, and only consuming them in munin-limits.
19:54:56 <sumpfralle1> Thus munin-limits would be more of "munin-alerts"?
19:54:57 <TheSnide> therefore munin-limits will be a mere alerting tool.
19:55:00 <TheSnide> yup
19:55:32 <TheSnide> it will therefore enable the red & yellow flags in htttp
19:55:39 <sumpfralle1> ?
19:56:05 <TheSnide> currently munin-http doesn't show any limits. Since they are not computed
19:56:46 <sumpfralle1> ok
19:57:00 * TheSnide admits to prioritize according to his mood, not according to real market analysis ;)
19:57:14 <sumpfralle1> now the limit-state would be stored in the database?
19:57:20 <TheSnide> yep
19:57:24 <sumpfralle1> mood is the best motivator imaginable :)
19:57:42 <TheSnide> nothing will be stored outside the db. (except for the rrd, of course)
19:58:15 <TheSnide> #topic munin-c
19:59:18 <TheSnide> We cannot use multi-homed plugins (such as the SNMP ones), as there's no support for multi-hosted node in munin-c
19:59:39 <sumpfralle1> that means: no plugin state based on the requester?
19:59:45 <sumpfralle1> or are there more requirements?
19:59:46 <TheSnide> nope
19:59:54 <TheSnide> means 2 things :
20:00:01 <TheSnide> - no plugin state based on the requester?
20:00:27 <TheSnide> - when a plugin emits "hostname", the munin-node-c just ignores it.
20:00:59 <TheSnide> then you cannot have "virtual hosts", such as routers from SNMP plugins on a central node.
20:01:11 <TheSnide> http://guide.munin-monitoring.org/en/latest/tutorial/snmp.html
20:01:46 <sumpfralle1> I never used this, but could imagine that people liked this. Anyway: you will have reasons ...
20:02:31 <TheSnide> My reasons are "i'm not monitoring routers via SNMP"... but it's *highly* convenient for a large number of users. or at least it was
20:02:53 <TheSnide> ... and the implementation to support it isn't trivial to get right.
20:03:46 <TheSnide> Also, another point of munin-node-c is more the systemd startup scripts. We need a way to launch the 1sec plugins to daemonize themselves.
20:04:07 <TheSnide> ... and systemd is precisely designed to prevent rogue processes ;)
20:04:43 <sumpfralle1> Do you feel that the 1sec plugins are an important feature? (I have no opinion about them right now)
20:04:49 <TheSnide> So i was thinking about implementing a "munin-run * aquire"
20:05:34 <TheSnide> sumpfralle1: I really like them. And 1 sec is much better than the usual 5s of the competition... #marketing
20:05:49 <sumpfralle1> #keepitsimple :)
20:06:05 <sumpfralle1> what is the "aquire" about?
20:06:37 <TheSnide> also, it enables very nice analysis, like http://demo.munin-monitoring.org/munin-monitoring.org/demo.munin-monitoring.org/multicpu1sec-pinpoint=1530122491,1530129812.png?size_x=800&size_y=400
20:06:55 <TheSnide> it's a new command for a plugin.
20:07:11 <TheSnide> it's says : "daemonize yourself"
20:07:34 <TheSnide> i made that up lately, so it's not really official yet
20:07:48 <sumpfralle1> thus we could allow persistent data flow connections (separate for different plugins)?
20:07:54 <TheSnide> nop
20:07:56 <TheSnide> e
20:08:07 <TheSnide> the idea is more having :
20:08:27 <TheSnide> $ munin-run cpu1sec acquire
20:09:03 <TheSnide> $ ... returns but leaves cpu1sec running in the background filling the state file.
20:09:06 <TheSnide> then
20:09:14 <TheSnide> $ munin-run cpu1sec fetch
20:09:37 <TheSnide> ... just does a "cat cpu.statefile && truncate cpu.statefile"
20:10:10 <sumpfralle1> The statefile follows the usual munin network protocol, but includes timestamps?
20:10:20 <TheSnide> Prior that, i tried to implement the forking automatically when detecting it didn't fork yet
20:10:26 <TheSnide> while asking for "config"
20:10:36 <sumpfralle1> that sounds hairy :(
20:10:37 <TheSnide> ... it is nice, but very error prone
20:10:52 <TheSnide> The statefile follows the usual munin network protocol.
20:11:12 <TheSnide> the protocol already suports timestamped values
20:11:30 <TheSnide> field1.value 123456:VALUE1
20:11:36 <TheSnide> field1.value 123458:VALUE2
20:11:38 <sumpfralle1> supports, but not necessarily contains?
20:11:44 <TheSnide> field1.value 123459:VALUE4
20:11:45 <TheSnide> ...
20:12:02 <TheSnide> if you emit the "standard" one:
20:12:02 <sumpfralle1> thus the 1sec plugin is required to add these?
20:12:08 <TheSnide> field1.value VALUE
20:12:36 <TheSnide> the munin-update translate it internally to "field1.value $(now):VALUE"
20:12:54 <TheSnide> yes
20:13:16 <TheSnide> https://github.com/munin-monitoring/contrib/blob/master/plugins/network/if1sec_
20:13:33 <TheSnide> and it's C counterpart https://github.com/munin-monitoring/contrib/blob/master/plugins/network/if1sec-c.c
20:14:06 <sumpfralle1> I am not really sure, if a new argument is required for this.
20:14:29 <TheSnide> it isn't. but it makes it plainly obvious.
20:14:33 <sumpfralle1> Would it be currently allowed to return more than one value on fetch? (with different timestamps)
20:14:49 <TheSnide> it is.
20:14:53 <sumpfralle1> ok
20:15:00 <sumpfralle1> could we use munin-async here?
20:15:08 <sumpfralle1> It stores and transports the statefile, or?
20:15:13 <TheSnide> old munin version will only use the last value actully
20:16:12 <TheSnide> munin-async is a differnt beast. It basically calls the node directly locally. then spools the data and hand it back when asked by the master
20:16:31 <TheSnide> ... it is the same idea, but on a differnt level.
20:16:41 <TheSnide> ... it also spools the config part.
20:16:49 <sumpfralle1> And the idea (and its implementation) is not reusable for this purpose?
20:17:17 * sumpfralle1 does not want to interfere with plans, but he has the sleight feeling, that there could be a simpler approach with the current tools
20:17:19 <TheSnide> the "1sec" part was designed *specifically* to avoid forking & opening files.
20:17:37 <TheSnide> to have the _lowest_ impact possible.
20:18:34 <TheSnide> Just have a look at the C version of the 1sec plugins. They are *DAMN* efficient.
20:18:50 <sumpfralle1> No doubt about that. We will need the same "transfer state" handling as munin-async uses now, or?
20:19:04 <sumpfralle1> (tracking whom requested the data from us when)
20:19:29 <TheSnide> not really. It just "flock()" & "ftruncate()"
20:20:03 <TheSnide> only 1 master is supported. If you need multiple master, you have to launch multiple daemons.
20:20:11 <sumpfralle1> munin-async does it differently, or? Was that a good approach?
20:20:31 <TheSnide> the munin-async approach is much older. and much more naive.
20:21:03 <TheSnide> It works pretty well, but the implementation turned out to be way more tricky than expected.
20:21:22 <TheSnide> --> and I'd like to rewrite it in a munin-async-c
20:21:23 <sumpfralle1> I can imagine that.
20:21:28 <sumpfralle1> ha! :)
20:21:34 <TheSnide> but... ENOTIME
20:21:52 <sumpfralle1> I was hesitant to propose a rewrite of it all in python - and you are silently doing it into C :)
20:22:04 <TheSnide> no, not python.
20:22:23 <sumpfralle1> Everyone has his beloved pet :)
20:22:24 <TheSnide> I mean, Python isn't much better than Perl.
20:22:43 <TheSnide> apart of the "massive amount of devs"
20:23:05 <sumpfralle1> "me" being part of this amount of devs would be my reason :)
20:23:12 <sumpfralle1> but that is not sufficient, I know
20:23:15 <TheSnide> and, everything that runs on the node always felt like a match for C.
20:23:31 <TheSnide> - efficiency
20:23:36 <TheSnide> - portability
20:24:01 <sumpfralle1> the permission handling on windows will be a nightmare :)
20:24:05 <TheSnide> Portability was once the promise of Perl... and it somehow failed
20:24:27 <TheSnide> permission handling in windows is "disabled". period.
20:25:02 <TheSnide> and python hasn't got any better in terms of portability.
20:25:34 <TheSnide> and. The *real* reason is "it's fun".
20:25:48 * sumpfralle1 is happy with that
20:26:18 * TheSnide is quite bored with multi terabytes JVM at work ;)
20:27:04 <sumpfralle1> We can offer your a shelter of minimal ressource usage under munin's wings :)
20:27:15 <TheSnide> yeap.
20:27:24 <TheSnide> i miss my Z80 days
20:27:37 <sumpfralle1> now you sound _old_ :)
20:27:51 <TheSnide> that's because i am!
20:27:57 <sumpfralle1> congratulations!
20:29:59 * TheSnide started with soldering on a Veroboard ;)
20:30:42 * sumpfralle1 is too young (or grew up in the wrong country) to know such a thing ...
20:30:49 <TheSnide> https://en.wikipedia.org/wiki/Veroboard
20:31:21 <TheSnide> was quite a thing in the 80's
20:31:34 <sumpfralle1> I thought, it still is :)
20:31:53 * sumpfralle1 did not know the name, but the style
20:32:06 <TheSnide> yeah, now everyone uses plastic ZIP breadboards
20:32:18 <TheSnide> s/ZIP/ZIF/
20:32:32 <TheSnide> anyway.. i think we can close the meeting ;)
20:32:37 <sumpfralle1> :)
20:32:45 <sumpfralle1> summarizing: you enjoy progressing!?
20:33:03 <TheSnide> i do.
20:33:07 <sumpfralle1> yeah!
20:33:13 <sumpfralle1> se let's continue!
20:33:15 <sumpfralle1> so
20:33:20 <sumpfralle1> #endmeeting