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

[Yves Mettier]

Hello,

> 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.

Some do not read more than one config block (I don't remember which one 
I found recently).
About this, I have a question (that should maybe be discussed in 
another thread) : I have a generic config file. How do I do with 
specific configurations ?

One solution is to have a centralized configuration (and deploy it with 
puppet or some similar tool).

Another solution would be to have a generic configuration file and 
another file that override the definitions of the generic one.
Why do I say that here ? Because the "Include" directive already 
exists, and if you decide to take into account one and only one <plugin> 
block (and define if you take the first or the last one), this should be 
the solution to my problem. I "include" the specific configuration file 
at the right place (first or last line in the configuration file) and 
any <plugin> block in the included file will override the block in the 
generic one.

Yes, if possible, make that only one <plugin> block is read for one 
plugin.


> 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).

I understand what a a deconfig_cb would do, is useful to distinguish 
the 2 sections <free the memory> and <allocate memory for configuration 
items>.
But what do you want to do with a deconfig_cb() without a reconfig_cb() 
?

And what is the difference between the config_cb() (the one that 
already exists) and reconfig_cb() ?


> 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.

Right.
About the local allocated memory, how can you ensure that everything is 
freed at unload time ? Only on the developer's responsibility ?

> 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.

Thinking about my recent jsonrpc plugin (already usable but not yet 
finished), do you think that it will share functions with unixsock ? 
Like deconfig/reconfig, unload/reload... ?
https://github.com/collectd/collectd/pull/154

Regards,
Yves

-- 
- Homepage       - http://ymettier.free.fr                             
-
- GPG key        - http://ymettier.free.fr/gpg.txt                     
-
- C en action    - http://ymettier.free.fr/livres/C_en_action_ed2.html 
-
- Guide Survie C - http://www.pearson.fr/livre/?GCOI=27440100673730    
-