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