19:15:55 <sumpfralle2> #startmeeting 19:15:55 <MeetBot> Meeting started Wed Jul 25 19:15:55 2018 UTC. The chair is sumpfralle2. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:15:55 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:16:12 <sumpfralle2> #chair dipohl TheSnide h01ger bcg chteuchteu be0rn kenyon 19:16:12 <MeetBot> Current chairs: TheSnide bcg be0rn chteuchteu dipohl h01ger kenyon sumpfralle2 19:16:41 <sumpfralle2> who wants to go forward with a topic? 19:16:43 <dipohl> #topic epel package 19:17:33 <dipohl> Good news! bcg will build Epel packages for the new Munin stable version :-) 19:17:49 * sumpfralle2 cheers! 19:18:03 <dipohl> https://bugzilla.redhat.com/show_bug.cgi?id=1575261 19:18:47 <dipohl> I have been testing the existing "Foobar Linux" packages today and a lot of talk and exchange of thoughts with bcg 19:19:01 <sumpfralle2> "Foobar Linux"? 19:19:22 <dipohl> https://foobar.fi/en/linux/ 19:19:31 <sumpfralle2> ok - sorry for interrupting 19:20:29 <dipohl> we have some proposals for upstream 19:21:00 <dipohl> The epel package has different log directories for Munin node and master 19:21:47 <dipohl> this makes things easier especially in SELinux context 19:21:59 <sumpfralle2> I think, this will be also be useful for the Debian package. 19:22:05 <dipohl> but also with other permission issues 19:22:14 <sumpfralle2> (I am neutral about doing this in munin itself or in the packaging) 19:22:59 <dipohl> the change happened a long time ago in Epel, see this ticket 19:23:00 <dipohl> https://bugzilla.redhat.com/show_bug.cgi?id=885422 19:24:38 <sumpfralle2> I would not argue against that. Would you open a ticket with the settings used by epel? 19:24:39 <dipohl> I would be happy if upstream does it the same way in the future 19:25:39 <dipohl> yes I will. Thanks for being open for that proposal :-) 19:26:07 <sumpfralle2> Thank you for the suggestion :) 19:26:07 <dipohl> another improvement we developed is 19:27:53 <dipohl> deliver only _one_ file with plugin configuration (in Epel there is a bundle of config files with names that point to a context, like amavis df fw_ hddtemp_smartctl libvirt munin-node postfix postgres sendmail 19:27:58 <dipohl> ) 19:28:58 <dipohl> As we instruct users to store their changes in own config files, following this recommendation will result in many files.. 19:29:13 <sumpfralle2> On the Debian side h01ger and me are just thinking about the opposite direction: splitting up the one configuration file into many. 19:29:24 <dipohl> http://guide.munin-monitoring.org/en/latest/plugin/use.html#configuring 19:30:08 <dipohl> I don't see advantage in delivering many files, but some disadvantages 19:30:36 <dipohl> bcg and me have now done the following: 19:30:52 <sumpfralle2> I think, at the moment munin itself does not deliver any config files for plugins at all. Thus I think, this is free to decide for packagers? 19:31:14 <dipohl> put all the default configuration into file 00-default (so that they are read at first) 19:32:19 <dipohl> and empty munn-node, which is only left for documentation purpose (used in Munin Guide) with the following notice in the empty munin-node file 19:33:17 <dipohl> # We moved the default config to file 00-default 19:33:17 <dipohl> # as config files in this directory are read in alphabetical order. 19:33:17 <dipohl> # 19:33:17 <dipohl> # Documentation can be found in Munin-Guide: 19:33:17 <dipohl> # http://guide.munin-monitoring.org/en/latest/plugin/use.html#configuring 19:34:02 <dipohl> so much from here 19:34:51 <dipohl> sumpfralle2: I think, at the moment munin itself does not deliver any config files for plugins at all. 19:35:23 <dipohl> Is there no file /etc/munin/plugin-conf.d/munin-node in the repo? 19:35:42 <sumpfralle2> as far as I can tell: no 19:35:57 <sumpfralle2> Installation from source seems to require some effort :( 19:36:08 <TheSnide> configuration is not provided by upstream. 19:36:21 <TheSnide> only defaults are. 19:36:40 <dipohl> ok 19:36:45 <TheSnide> and packagers are already vastly diverging from the ones in the tgz. 19:37:07 <TheSnide> (which are _highly_ dubious) 19:37:12 <sumpfralle2> do we ship defaults? 19:37:13 <dipohl> but we could make the recommendation to call the file with default values in a way that it is read at first 19:37:38 <TheSnide> sumpfralle2: yes we do. but i hate it. 19:38:18 <TheSnide> that said, i never bothered changing it either. since the one in debian is perfect to me ;) 19:38:34 <sumpfralle2> If you know by heart, where that happens - I would be interested to take a look ... 19:38:38 * dipohl does a lot of adjustment 19:38:59 <sumpfralle2> Regarding the naming of the configuration file: I guess, the guide is the proper place for that? 19:39:04 <TheSnide> i can adjust the defaults if you want. 19:39:19 <TheSnide> packagers wont be affected since they override it anyway 19:39:24 <dipohl> TheSnide: the defaults are ok 19:39:34 <sumpfralle2> but where are they hidden? 19:39:47 <dipohl> but I have a lot of plugins that need manual adjustment for the special machine 19:40:15 <sumpfralle2> dists/tarball/plugins.conf? 19:40:21 <sumpfralle2> 2007! :) 19:40:28 <TheSnide> https://github.com/munin-monitoring/munin/tree/master/etc 19:40:31 <dipohl> and I suppose many users are not aware of the alphabetical read order 19:41:11 <sumpfralle2> But I am positively suprised, that the alphabetical order is mentioned in the guide. 19:41:18 <dipohl> In this perspektive I thing "munin-node" is not a good name for the defaults 19:41:33 <dipohl> yes, but do they read the Guide? ;) 19:42:12 <sumpfralle2> Otherwise we will tell them to do that :) 19:42:13 <dipohl> or the other way: If we recommend a name like "00-default" they don't have to read 19:42:21 <sumpfralle2> yes, indeed 19:42:33 <TheSnide> and https://github.com/munin-monitoring/munin/blob/master/Makefile.config 19:43:03 <TheSnide> +1 to avoid reading 19:43:11 <dipohl> :-) 19:43:23 <TheSnide> i man, if something can be made obvious, i'm all for it 19:43:29 <TheSnide> /mean/ 19:43:46 <sumpfralle2> Do we want to do that in both 2.0 and pre3.0? 19:44:08 <TheSnide> do not change 2.0 19:44:31 <sumpfralle2> I had the same feeling 19:44:32 <dipohl> if we left the file "munin-node" there and place the hint therein it will be ok to change also in stable version 19:44:45 <TheSnide> and release 3.0 (well.. that's for me) 19:45:31 <sumpfralle2> regarding the name of the configuration file: this is in the end really a packaging issue. The Debian packaging does not depend on the name proposed by munin. The same is probably true for epel 19:45:52 <dipohl> yes 19:45:55 <sumpfralle2> Thus I think, we do not need to introduce changes to 2.0 with limited practical effects. 19:46:06 <dipohl> and bcg and me are on that path described above 19:46:14 <sumpfralle2> good 19:46:59 <sumpfralle2> I would be interested in your outcome (and arguments) of the discussion regarding many sall config files. 19:47:07 <sumpfralle2> small 19:47:22 <dipohl> you will get a lot of merging work with it 19:47:35 <dipohl> if you made adjustments therein 19:47:45 <sumpfralle2> ? 19:47:48 <dipohl> postfix -> postfix.rpmnew 19:48:22 <dipohl> in the red hat world and also other rpm based distris 19:48:35 <dipohl> How do you make it in Debian? 19:49:00 <sumpfralle2> currently: single file; soon (probably): multiple files 19:49:33 <dipohl> I mean what do you do with config files delivered from the distri, if the user changed it? 19:49:34 <sumpfralle2> With the dpkg hanling of config files, this should be easy 19:50:02 <sumpfralle2> if changed: dpkg prompts the user (default: keep changed file) 19:50:17 <dipohl> so a lot of questioning during update.. 19:50:23 <sumpfralle2> otherwise: silently follow the packaging changes 19:50:25 <sumpfralle2> no 19:50:39 <sumpfralle2> people will rarely write into upstream config files 19:50:52 <sumpfralle2> at least, if they see the munin-conf.d/* thing 19:51:30 <sumpfralle2> (maybe expecting too much form mere humans - but I think, problems would be rare) 19:51:31 <dipohl> hmm, as said, I did make a lot of adjustments and all in "munin-node" at the time when there was only one file 19:52:08 <sumpfralle2> An obvious documentation hint at the top of the file should help most users avoiding that. 19:52:31 <sumpfralle2> but anyway: epel and Debian users may be different :) 19:52:41 <dipohl> and then the number of config files will raise 19:52:56 <dipohl> postfix (upstream), postfix (mine) 19:53:06 <dipohl> a.s.o. 19:53:35 <sumpfralle2> This is no issue from my point of view. With a good explanation of the proper way how to override settings, this should be easy. 19:53:46 <sumpfralle2> Anyway: epel and Debian may differ here, I think. 19:53:50 <dipohl> what is the advantage of many files? 19:54:27 <sumpfralle2> keeping the configuration of one plugin to the package where it belongs 19:54:35 <sumpfralle2> (we have many plugin packages in Debian) 19:54:40 <dipohl> ah 19:54:42 <dipohl> ic 19:55:09 <sumpfralle2> for now I am still convinced, that the split will be a good thing 19:55:19 <sumpfralle2> but we can discuss this later more detailed, if you like 19:56:09 <dipohl> anyhow: it would be good to name the distributed config files then also 01-postfix or similar 19:56:49 <sumpfralle2> I am still unconvinced, that anybody would notice, how the source configuration files are named :) 19:57:20 <dipohl> you mean the upstream files? 19:57:28 <sumpfralle2> In Debian the tools for configuration file handling are just there and useful. But in a source installation this would need to be done manually by the user. 19:57:29 <dipohl> I am talking about the delivered files 19:57:36 <sumpfralle2> upstream, yes 19:57:57 <sumpfralle2> is there a difference between upstream and delivered? 19:58:12 <sumpfralle2> (I would use both terms for the same: munin itself) 19:59:30 <dipohl> I thought we want to make some recommendations for packagers 20:00:11 <dipohl> the simple method: one file called 00-default 20:00:40 <sumpfralle2> We will do this for pre3.0, yes. 20:00:43 <dipohl> if you want many files, call them also 00-<something> or 01-<something> 20:00:58 <sumpfralle2> I would want them in Debian, but I am not sure, I want them in upstream. 20:01:50 <dipohl> the most important improvement is the hint, that the alphabetical order is relevant 20:02:11 <sumpfralle2> This will be done automatically by the filename. 20:03:05 <dipohl> but no one comes to the conclusion if the files represent the APPs name only 20:03:27 <sumpfralle2> Just from my perspective: I did not even know, that we shipped any plugin configuration files at all. 20:03:49 <sumpfralle2> Probably the five people here in this channel reading this discussion right now know. 20:04:23 <sumpfralle2> I think, it is fine to leave this to the packagers. They know the configuration tools of their systems and the expectations of their users. 20:05:19 <dipohl> ok, topic is finished then, right? 20:05:40 <sumpfralle2> I think, yes. 20:06:03 <sumpfralle2> #action sumpfralle2 rename plugin configuration file to digit-starting thing in pre3.0 20:06:39 <dipohl> #topic earlier summer meeting time 20:06:39 <sumpfralle2> any other topics after the happy epel surprise? 20:06:47 <sumpfralle2> :) 20:07:03 <sumpfralle2> Summer is half-way over :) 20:07:04 <dipohl> we have done this already in earlier years 20:07:53 <sumpfralle2> Now we just need a nice description of the time based on the date. 20:07:57 <sumpfralle2> Any proposals? 20:10:50 <dipohl> 19:30 UTC when there is no summer time and 18:30 UTC during period when we have CEST 20:11:19 <sumpfralle2> Good! 20:11:24 <sumpfralle2> This should go on the website, or? 20:11:51 <dipohl> would be good yes 20:11:56 <sumpfralle2> I will also mention it, when sending the IRC meeting around on the munin-user list. 20:12:02 <sumpfralle2> Would you do the website / trac? 20:12:19 <dipohl> thanks! and yes I can do 20:13:04 <sumpfralle2> #action change IRC meeting time from 19:30 UTC (all-year) to 19:30 in winter and 18:30 UTC while CEST is applicable 20:13:24 <sumpfralle2> #info change IRC meeting time from 19:30 UTC (all-year) to 19:30 in winter and 18:30 UTC while CEST is applicable 20:13:31 <sumpfralle2> other topics? 20:13:51 <dipohl> #action dipohl add info about changing meeting times during summer and winter in the trac wiki / github wiki 20:14:58 <dipohl> #topic Plugin Gallery 20:15:38 <dipohl> what is the state concerning roll-out of your improved new version? 20:15:51 <sumpfralle2> it is not there, yet 20:15:53 <sumpfralle2> next week, sorry 20:16:22 <sumpfralle2> #action sumpfralle2 populate the new server with the fresh demo installation 20:16:29 <dipohl> no problem, take your time - there are more important issues than that.. ~ 20:16:58 <sumpfralle2> Do you see pressing ones? 20:17:44 <dipohl> reduce the number of open issues? 20:18:26 <dipohl> https://github.com/munin-monitoring/munin/issues 20:20:34 <dipohl> setup a new Munin homepage? 20:20:37 <sumpfralle2> I think, the issue tracker is in a healthy state. pre3.0 obviously is not feature-complete. And there are only a handful of issues for 2.0 that feel important ot me. 20:20:43 <sumpfralle2> The website sounds more important. 20:21:22 * sumpfralle2 thinks Munin feels quite lively right now 20:21:43 <dipohl> I have the same feeling ~ :-) 20:22:03 <dipohl> let's hope it stays for a while 20:22:55 <sumpfralle2> yeah! 20:23:40 <sumpfralle2> Regarding the website: should we just - at some point - abandon the remainder of the non-migrated wiki from trac? 20:24:00 <sumpfralle2> I rarely need to use links from there anymore - everything important seems to be in the guide. 20:24:14 <dipohl> as said in the last meeting, I have not much time at the time.. 20:24:28 <sumpfralle2> No problem - no pressure intended 20:24:40 <dipohl> I will focus on testing of the new epel packages 20:24:58 <dipohl> concerning the trac wiki 20:25:29 <dipohl> I would like to have access after switching to the new homepage 20:25:47 <dipohl> until all content has been moved or deleted 20:26:48 <sumpfralle2> We will do a backup (crawler dump). 20:26:58 <sumpfralle2> Let's say: I will migrate three pages and you will migrate three pages (or less) and then we just move on to the new website? 20:27:09 <dipohl> perhaps we can setup the new homepage during winter 2018/2019? 20:27:25 <sumpfralle2> Do you think, there is so much to be done? 20:27:54 <sumpfralle2> chteuchteu would take a look and advise us how to publish it. 20:28:04 <sumpfralle2> Then the outdated stuff needs to be refreshed. 20:28:07 <sumpfralle2> Step by step ... 20:28:16 <dipohl> I hope not, but I have to share my rare time between Munin-Guide and Homepage 20:28:42 <dipohl> and know nothing about the homepage technology yet 20:29:07 <sumpfralle2> hopefully trivial - otherwise I will prepare something on the server 20:29:26 <sumpfralle2> Let's say: I will migrate three pages and you will migrate three pages (or less) and then (whenever that is) we just move on to the new website? 20:29:35 <sumpfralle2> should we do it this way? 20:29:48 <sumpfralle2> (otherwise we will delay it ad infinitum, I fear) 20:30:42 <dipohl> hmm, but let's start in autumn, not now 20:31:23 <sumpfralle2> ok 20:31:35 <dipohl> it would be good to launch the new homepage with Munin 3.0.. 20:31:36 <sumpfralle2> #info Website shall be migrated in autumn 20:31:48 <sumpfralle2> other topics? Or should we finish? 20:32:09 <dipohl> TheSnide: can you see a launch date for Munin 3.0? 20:34:08 <dipohl> no more topics from my side 20:34:35 <sumpfralle2> ok - so we are closing for now. 20:34:38 <sumpfralle2> #endmeeting