On 01/07/13 01:18, Frank Ch. Eigler wrote:
...
If it were not too much work, I'd rather see generated files distinct
from hand-made files. Perhaps pmlogger et al. could run pmcpp on its
configuration file (and let the generated one be #include'd), or
search a directory and consume the union of the files there.
This would appear to pass the "not too much work" pre-condition. The
only issues that I can see are ...
1. pmlogger config file syntax does not include a version header (unlike
some of the other config files we define and use), so we'd need to
invent one going forward, or add some keyword glue at the start of the file
2. pmlogger config files use sh-like commenting, so comment lines
beginning with # are not going to work all that well with pmcpp (or any
other cpp look alike) ... we'll probably need some sed | pmcpp | sed
logic to make this transparent
If we do 2., then 1. may not be required ... always preprocess and
existing config files are unchanged.
The idea is small:
- to have running pmcd's announce themselves on the
local net via DNS-SD = avahi = zeroconf
- to have pmlogger or pmlogconf or whatnot tool monitor the DNS-SD
announcements, and create/shutdown new pmlogger instances for them.
Basically, auto-configured network-wide logging on designated central hosts.
This is a great idea.
I have one immediate application where this would be most useful in load
balanced cloud-land where the servers comes and go as load dictates.
|