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

[Jehan-Guillaume de Rorthais]

On Wed, 4 Apr 2018 10:54:12 +1000
Andrew Beekhof <abeekhof at redhat.com> wrote:
...
> > > > 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  
> >
> > Please find in attachment a demonstration of such behavior I found last
> > week.
[...]
> No, none of these are out of order.

Well, so I don't understand why, but anyway, I'll try to figure at some points.

Please find in attachment another example taken from this issue:

  https://github.com/ClusterLabs/PAF/issues/131#issuecomment-381182955

In this file, messages from lines 129-184 and 192-209 all comes from the
**same** pre-notify promote action in PAF resource agent.

However, you will notice CRM already wrote to the log the final result of this
action at L.128. Just before the actual logging of the action itself.

Moreover, right in the middle of these messages, L.185-191 are some reactions of
CRMd to a failing promote action that is supposed to happen **after** the
pre-notify promote finished. Plus, L.188, we can clearly find CRM triggering the
post-promote notify where the pre-promote notify action is still logging
informations...

I understand there is a bunch of processes all logging together to the same
place. Cherry on the top, a lot of events are triggered asynchronously... Trying
to keep messages order is probably impossible...

And I understand this makes messages log arriving in random order, making the
analysis of the logs a major pain for users (new or experienced), with sometime
effects are logged after causes :/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pg2-dev_journald
Type: application/octet-stream
Size: 239083 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180413/879532ec/attachment-0002.obj>