Hi again, just a few more notes / detail …
On Thu, Oct 11, 2012 at 09:11:24AM +0200, Sebastian Harl wrote: > Now, my idea is to introduce a "reconfigure" callback that allows to > reconfigure a single plugin. This could then be exposed, for example, > through the 'unixsock' plugin. > > Example: > > /* plugin.h */ > int plugin_register_reconfig (const char *name, > int (*callback) (oconfig_item_t *)); > > /* UNIXSOCK */ > RECONFIGURE <PluginName> > > Obviously, "reconfigure" will fail if the specified plugin did not > register a "reconfig" callback. In case, the plugin did not specify a > "config" callback either, "reconfigure" could be a no-op (no error). > > Internally, the callback would trigger re-parsing the whole > collectd.conf file. Then, the appropriate config-block would be > dispatched to the registered "reconfig" callback just in the same way > that the original configuration was dispatched to the "config" callback. When thinking about the detailed side-effects, I came across the following: currently, collectd allows to specify multiple <Plugin> blocks for a single plugin. This is not documented anywhere and should not be considered to be officially supported. The current behavior greatly depends on the plugin. However, quite a few plugins probably handle this situation sanely and, thus, this might be used in a couple of reasonable use-cases. Now, when thinking about a "reconfig" operation, most plugins will probably de-configure and re-read the new configuration (possibly leaving some caches or certain state-information in place). Obviously, this would not work if there are more than one <Plugin> blocks. I.e., a plugin would behave differently when being configured and when being re-configured. The question is if this should be considered at all (after all, it's not officially supported). However, by splitting the "reconfig" into "deconfig" and "reconfig" (or "config"), we could easily handle this situation as well. So, I suggest the following: - typedef int (*deconfig_cb) (void); - typedef int (*reconfig_cb) (oconfig_item_t *); That is, 'deconfig' would use the same signature as 'shutdown' and 'reconfig' would use the same signature as 'config'. This would allow to use the appropriate callbacks twice, which in most cases should be sufficient (probably plus some checks for current settings). Any thoughts, comments on this? > As a second step we could then think about also implementing a "reload" > action. This would mean unloading and reloading the shared object of a > plugin and then doing a "reconfigure". In fact, thinking about this again, I think that a global reload should not unload and re-load the shared objects (but possibly unload plugins that are no longer used and load new plugins). Else, it's gonna be hard to keep plugin-global information (caches, etc.) in place. However, a second operation (available through the 'unixsock' plugin and similar) could be used for that case if anybody comes up with a use-case for that. Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
_______________________________________________ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
