[collectd] RFC: implementing reload/reconfigure (was: New aggregator plugin "basic_aggregator" (#136))

[Sebastian Harl]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20121013/7239b6a3/attachment.pgp>