Hey guys,
----- Original Message -----
> On 13/07/13 06:44, Frank Ch. Eigler wrote:
> >
> > nathans wrote:
> >
> >> [...]
> >> this server process would not need to run pmlogconf/pmieconf, I think.
> >
> > Considering kenj's problems, I believe that running pm*conf from the
> > cron FOO_check.sh is not a good idea after all...
>
> I agree. It would seem to be prudent to separate the initial config
> file generation based on the local environment to something that is done
> once post-install, and possibly could be redone later by hand if
> required (e.g. if the local environment changes without a PCP
> install/upgrade).
>From earlier discussion, AIUI, Frank was advocating no-auto-generation
of config files. I'm not 100% sure why though - there was some initial
thinking around possibly violating packaging policies, but perhaps it's
more a general vibe of not liking to mix generated and manual configs.
I do believe it can be acceptable to generate default config files. To
my mind, the resolver configuration says others have crossed this bridge
with far, far more critical configuration files. The packaging would be
similar for us - we now have no package providing a pre-canned default
config (since, in practice, that has proved impossible - though I'm not
sure I have really convinced Frank of that either).
$ rpm -qf /etc/resolv.conf /etc/pcp/{pmie,pmlogger}/config.default
file /etc/resolv.conf is not owned by any package
file /etc/pcp/pmie/config.default is not owned by any package
file /etc/pcp/pmlogger/config.default is not owned by any package
Moving on... if we are going to generate configs, as at least Ken and
I seem to agree we should, then we may as well do a good job of it.
Doing it once, post-install, defeats alot of what that last pmlogconf
iteration was all about (which was based on years of experience with
an Aconex production environment pmlogconf-alike tool).
pmlogconf is able to handle different / extra agents being installed
(which are not choices that can be made for pmlogger configs built at
package install time), and differences between platforms. And the
matrix of those things being either remote or local too. If we did
generate once, only, and never again, then for no real reason we'd be
tossing out alot of functionality that was specifically built in, and
kittens would surely die as a result.
So, I continue to believe in the long-standing pmieconf/pmie_check
model, and also remain happy to make pmlogconf/pmlogger_check behave
similarly.
Clearly aspects can be improved, and there will be the inevitable
bugs - but its far and away the best, most mature solution available
to us right now for our next and other short-term releases.
> > Overall, the _check scripts don't seem to be a very good fit for
> > robust and rapid management of pmlogger/pmie lifecycles. It seems
> > like we'd need a baby init(8) or systemd(8).
>
> This is a new (and important I agree) use case that probably warrants
> some new engineering thought and execution, rather than trying to weld
> something onto the 10+ year old cron-script framework.
In my experience, it can be welded on just fine - Aconex have been doing
that for years (not quite as dynamic as in a cloud but still dynamically
adding pmlogger-recorded-hosts without administrator intervention).
New mechanisms, models, ideas and experimentation are of course welcome
as well. No doubt, over time, better approaches will evolve and we can
move to them as they become available/implemented (and tested/stable!).
cheers.
--
Nathan
|