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

[Andrew Beekhof]

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


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


>
> > and also to easily see the XML syntax was as expected.
>
> And this can go to detail/debug logs I suppose.
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180329/671f91a2/attachment-0002.html>