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

[Jehan-Guillaume de Rorthais]

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 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 :/

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.

> > > 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.