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

[Yves Mettier]

Hello,

Today, I'm working on the nfs plugin (adding stuff for 
/proc/self/mountstats). And I thought that supporting reconfig would be 
nice. So I'm reading this mail again...
Some new comments are here.

>> Example:
>>
>>   /* plugin.h */
>>   int plugin_register_reconfig (const char *name,
>>           int (*callback) (oconfig_item_t *));
>>
>>   /* UNIXSOCK */
>>   RECONFIGURE <PluginName>


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

Having deconfig + reconfig is definitely a good idea because the 
developer has to think how to "free" the memory allocated with 
config/reconfig and cannot produce bad code with fastly coded 
update_config() function.

>  - 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 like typedef int (*reconfig_cb) (oconfig_item_t *);
Because of the same signature as 'config'. But in reality because of 
the signature of "config_complex".
What about "config simple" ?

In my mind, most plugins will have the same callback for config and 
reconfig. So I suggest :

- typedef int (*deconfig_cb) (void);
- typedef int (*reconfig_cb) (const char *key, const char *value);
- typedef int (*reconfig_complex_cb) (oconfig_item_t *);

About the nfs plugin (currenly having no configuration at all, I will 
choose the config_complex mechanism) and will try to support these 
definitions (and hack something with stat() again before all this is 
implemented).

Regards,
Yves

>
> 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
>
> _______________________________________________
> collectd mailing list
> collectd at verplant.org
> http://mailman.verplant.org/listinfo/collectd

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