19:28:58 <sumpfralle4> #startmeeting
19:28:58 <MeetBot> Meeting started Wed Mar 25 19:28:58 2020 UTC.  The chair is sumpfralle4. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:28:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:29:15 <sumpfralle4> It is Wednesday evening again: time for our weekly IRC meeting.
19:29:58 <sumpfralle4> Anyone who wants to share some thoughts - this is your time! :)
19:52:56 <TheSnide> hi
19:53:24 <TheSnide> we spoke about having an "offboarding" of old plugins
19:56:42 <sumpfralle4> yes. How awould you approach this?
20:10:47 <TheSnide> i'd replace the output by a generic one, that says "U", and changes the graph_title & extinfo
20:11:17 <TheSnide> then we can symlink every old plugin to that one.
20:12:11 <TheSnide> and issue a something like "this plugin has been removed, please see http://mm0.eu/removal/$old_plugin_name"
20:12:52 <TheSnide> and we'll put a redirect at that page to an explanation page. Be it wiki, github issue, debian BTS or github commit.
20:13:32 <TheSnide> the $old_plugin_name is autogen by the plugin filename (as usual)
20:14:13 <TheSnide> I think that's rather easy to implement, even in /bin/sh
20:14:29 <TheSnide> while still be quite useful.
20:16:35 <TheSnide> ... also, instead of mm0.eu, we could leverage our http://guide.munin-monitoring.org/en/latest/removal/$old_plugin_name.html
20:17:04 <TheSnide> but the mm0.eu url was shorter
20:35:55 <sumpfralle4> This case would be similar to the case of a dead symlink in /etc/munin/plugins/, or?
20:36:53 <TheSnide> a dead symlink?
20:37:12 <sumpfralle4> The symptom is the same, or?
20:37:20 <TheSnide> ah, when there is a symlink, but the real file "disappears"
20:37:54 <TheSnide> no. in the missig symlink either the graph is removed, or the graph is stale
20:38:06 <TheSnide> here, the graph does change, with some useful information
20:41:01 <sumpfralle4> I have the feeling, that such a notification would be hard to implement in stable-2.0, since the plugin's data simply becomes stale and thus the graph is not displayed anymore.
20:41:57 <TheSnide> not at all.
20:48:52 <sumpfralle4> Right, I was side-tracked by the idea, that we would deliver a custom svg graph with some big red letters. But indeed if we want to embed the information into a simple plugin graph, then no one but the plugin itself would be involved.
20:49:58 <sumpfralle4> But I still doubt the usefulness of this approach. I am thinking about a use case like "apt-file search munin/plugins/asterisk". This would indicate, that there is a plugin, even though it is just a symlink to the dummy plugin.
20:54:40 <sumpfralle4> The issue is related to the generic case of a plugin being broken in some way. Dead symlinks are not reported by munin-node to the master, since the existence test for the file fails. Thus the master never receives the message, that a seemingly configured plugin is missing. The similar case of a plugin causing errors and invalid output during execution at least appears in the master's
20:54:42 <sumpfralle4> log (munin-update.log).
20:56:44 <sumpfralle4> Currently the master just dismisses this kind of information (due to the lack of storage for any information besides the actual plugin data). At least for munin 3.0 we could store such meta information (broken plugin, dead symling) in the database and present it in the host visualization.
20:57:35 <sumpfralle4> This is what you are looking for, or? Some kind of "this plugin is missing/broken/removed" indication in the host view?
20:57:50 <TheSnide> now, what is better ? having apt-file returning an "dummy" one or nothing?
20:58:08 <TheSnide> yeah. i'd like to show it in the UI
20:58:12 <sumpfralle4> nothing - because it is not there
20:58:50 <TheSnide> hmmm... maybe it's not such a good idea afterall.
20:59:15 <sumpfralle4> But I like the more generic idea of indicating broken/missing plugins.
20:59:50 <sumpfralle4> For missing plugins we would surely phrase something like "maybe it was removed from munin" or similar.
21:02:36 <sumpfralle4> At the moment munin-node does not return dead symlinks in its "list" view. Maybe it would be a good idea to change this? Then the master (probably only starting with 3.0) could show an indication for such a problem.
21:05:08 <TheSnide> hmmm... dead symlinks handing in node might be good for 3.x indeed.
21:15:25 <sumpfralle4> I will take a look at the effects of changing this in munin-node.
21:17:48 <sumpfralle4> Finalizing the discussion about plugin removal: we just remove them?
21:41:21 <TheSnide> yup.
21:41:31 <TheSnide> yup. remove.
22:14:07 <sumpfralle4> Fine. I will prepare another release in the next days.
22:14:09 <sumpfralle4> #endmeeting