[ClusterLabs] Possible idea for 2.0.0: renaming the Pacemaker daemons

[Andrew Beekhof]

On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais <
jgdr at dalibo.com> wrote:

> On Thu, 29 Mar 2018 09:32:41 +1100
> Andrew Beekhof <abeekhof at redhat.com> wrote:
>
> > On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <
> > jgdr at dalibo.com> wrote:
> >
> > > On Wed, 28 Mar 2018 15:50:26 -0500
> > > Ken Gaillot <kgaillot at redhat.com> wrote:
> > > [...]
> > > > > >  pacemakerd: PREFIX-launchd, PREFIX-launcher
> > > > >
> > > > > pacemakerd, alone, sounds perfectly fine to me.
> > > >
> > > > Agreed -- but the argument against it is to allow something like
> "grep
> > > > pcmk /var/log/messages" to get everything.
> > >
> > > Then I would pick PREFIX-master... But then I would hate having a
> > > pcmk-master
> > > process :(
> > >
> > > Maybe all the logging information should be handled by one process so
> > > syslog/journald/stderr are happy?
> > >
> > > Despite it's multiprocess architecture, PostgreSQL either:
> > >
> > > * emit to syslog/journald using the same ident for all process
> > > * capture stderr of all process and redirect to one file.
> > >
> > > [...]
> > > > > >  cib: PREFIX-configd, PREFIX-state
> > > > >
> > > > > Tricky...It deals with both config and state...
> > > > >
> > > > > By the way, why in the first place the CIB messages must be in the
> > > > > log file?
> > > > > Filling logs with XML diffs resulting from other actions already
> > > > > logged earlier
> > > > > sounds like duplicated informations.
> > > >
> > > > They are kept out of the syslog, which is where most users are
> expected
> > > > to look. They are in the detail log, which is for more advanced
> > > > troubleshooting.
> > >
> > > oh ok, sorry.
> > >
> > > I just finished a day reading log file /var/log/pacemaker.log on a
> Suse 12
> > > SP1
> > > that was packed with XML diffs :/
> > >
> > > Maybe I should have checked /var/log/messages or the syslog setup...
> > >
> > > But honestly, I hate having mixed logs all packed in one same files
> > > like /var/log/messages :/
> > >
> >
> > Theres a very good reason for it though - the relative timing of events
> is
> > the only way to establish cause and effect.
>
> Yes. But sometime, messages are not so well mixed, with causes showing up
> after
> effects in logs...
>
> > Though by now there is surely a decent library for logging to files with
> > sub-second timestamps - if we could incorporate that into libqb and have
> > corosync use it too...
>
> In my opinion, this is neither the role of libqb


libqb has the logging library that pacemaker and corosync use.
it is absolutely where this change should happen



> or corosync...Or you would
> have to include some more configuration params to be able to set the log
> directory, file, format, rotation, etc.
>
> Maybe the easiest path is to rely on syslog/journald. They are both able
> to log
> with sub-second timestamps (at least journald do) and provide the
> administrator
> everything they need to deal with the logs.
>
> > then we could consider 1 log per daemon.
> > In which case, the outcome of the PREFIX-SUFFIX discussion above could
> > instead be used for /var/log/pacemaker/SUFFIX
>
> I think the best would be to have one log for Corosync, one log for
> Pacemaker
> (and all its sub-process/childs).
>
> Another good path toward understandable log file would be to hide what
> process
> is speaking. Experienced user will still know that "LOG: setting failcount
> to 3" comes from CRMd and "DEBUG1: failcount setted to 3" comes from attrd.
>
> However, this would probably be a mess...because again, the cause might be
> logged AFTER the effects/reaction :/
>

why?  i've never seen that be the case


>
> Maybe the solution is to log only messages from CRMD, where all the
> orchestration comes from. Everything else might go to some debug level if
> needed.
>

sorry, that is a terrible idea


>
> > > > The detail log messages are useful mainly because CIB changes can
> come
> > > > from external sources, not just cluster daemons,
> > >
> > > Sure, but a simple info messages explaining that «the CIB has been
> updated
> > > by
> > > tool "<tool_here>" » sound enough to me.
> > >
> >
> > to you, because you know what you changed.
> > anyone else reading the logs (ie. people doing support) hasn't got a clue
> > and knowing who changed what is crucial to understanding what the cluster
> > did and why
>
> I'm doing some support as well, infrequently. I suppose crm_report is
> probably
> enough to gather previous CIB and compare them.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180403/088680d2/attachment-0001.html>