Hi, Nato -
nathans wrote:
> ps: I'm away for 3 weeks, starting .... now. See you next
> year, I hope you have a safe and enjoyable holiday season!
Welcome back!
> [pmmgr man page]
>
> No config comments allowed? Just README - someplace else though?
> seems a bit harsh. *shrug* - good reasons for the rigidity I hope.
It makes parsing bulletproof and absolutely trivial.
> Man page style - command names usually in bold in PCP man pages.
Fixed.
> [build/makefiles]
> pmmgr not on windows? (pmcd+pmdas & libpcp shows how it can be done)
> - this would be really good to have there [...]
Agreed, maybe in the not-too-far future.
> [...]
> [pmmgr]
>
> log-directory config file hard-codes /var/log/pcp ... use $PCP_LOG_DIR?
> (can these config files have embedded env vars?)
Dropped that. That and other .default files were there to document
(redundantly with the man page) the built-in defaults.
> target-discovery.avahi contains avahi? (latter seems superflous)
Renamed the file. Or the existence of a target-discovery.avahi file
could be intereted as a request to do the job, instead of just from
lines from the target-discovery file.
> misspelt pmwebd reference in rc_pmmgr still (cut&paste - patch attached)
Thanks.
> makefile - targets (not macros) need platform protection via ifneq -
> e.g. see each of the platform PMDAs makefiles, and "build-me" (so, don't
> build/install at all if not supported, but CFILES/HFILES/LSRCFILES still
> needs to be set)
Fixed.
> (remove MINGW refs in code - makefile guarantees this for us, until
> someone does a port - so its just distracting noise in there too)
Fixed.
> Log merging - via pmmgr_pmlogger_daemon::daemon_command_line side-effects?
> This part feels a bit hacky - wonder if these helper programs could be
> more "designed in", somehow, perhaps with their own helper interfaces
> (that routine has got pretty big... and has all sorts of extra goodies
> unrelated to daemon command lines).
Yeah. I leaned toward simplicity (as is) versus power (an elaborate
state machine).
> Log file naming conventions - one of the issues with the current
> scheme is that a host can end up with many, many archives in one
> directory [...]
The current code does a log-merge of all previous archives into one,
doing data-aging at the same time, so thar particular type of trash
doesn't pile up.
> Log rewriting (pmlogrewrite) seems to be missing? (nor in the todo)
Will add to the TODO. Is that urgent?
> I like the host-id stuff - neat approach! :) I wonder if we should
> take some steps (sort?) to attempt to ensure a given series of metrics
> will always give the same host-id (for same values returned of course).
That is already done.
> I was half expecting this to be all threaded - especially the bits that
> restart each daemon & merge logfiles and so on - we'll block in those
> spots, so one slow merge/reconfig/restart slows all, and daily logger
> restart gets slower with more and more hosts...? *shrug*
Added per-host-id threading during the poll stage, allowing multiple
pmlogconf/etc. analyses to run concurrently.
> [packaging]
>
> What's the plan? If we want to allow people to pick and choose between
> cron-based and pmmgr-based (which I imagine we do) we need to split both
> styles into separate rpms which replace/conflict with each other, I think?
They don't need to conflict in any mechanical sense, and they run fine
(unaware of each other) side-by-side.
> pcp-manager-static and pcp-manager-dynamic? (maybe Provide: pcp-manager
> from both, and pcp could depend on that virtual package?)
I wouldn't suggest anything that clever. They're not plug-in
substitutes for one another. I'd just let people transition if they
like (or want the new features).
> The pmie and pmlogger rc scripts (and associated chkconfig state) are no
> longer used in this scheme AIUI, right? (nice) If so, all of:
>
> /etc/rc.d/init.d/pmlogger
> /etc/cron.d/pcp-pmlogger
> /etc/pcp/pmlogger/control
> /etc/pcp/pmlogger
> /usr/libexec/pcp/bin/pmlogger_check
> /usr/libexec/pcp/bin/pmlogger_daily (?)
>
> (and pmie equivalents) would move into pcp-manager-static, I think [...]
Yes, that's a possible way to segregate the might-be-deprecated-eventually
files, if it became urgent. I started prototyping this, but was frightened
off by the way the manifest files are generated then munged into rpm
spec %files lists. Is there still a need for something like that (as
opposed to simple directly-specified list of files/directories)?
> Also, should plan out what happens when someone switches from one approach
> to the other (and back again), cos its bound to happen whether by accident
> or not - we need to have thought it through (test) and make sure its safe.
They don't conflict, so that should be fine. OTOH, they don't carry
archives across from one another, which might be desirable. (For
pmmgr, one'd just drop the archive files in the relevant
/var/log/pcp/pmmgr/HOSTID subdirectory; they'd get merged/aged after
that.)
- FChE
|