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