Bug 1479009 - [RFE] consider timestamped journal of the past pcs commands
Summary: [RFE] consider timestamped journal of the past pcs commands
Keywords:
Status: CLOSED DUPLICATE of bug 1427495
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-07 17:12 UTC by Jan Pokorný [poki]
Modified: 2018-01-09 11:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-09 11:49:24 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1359057 None None None Never

Internal Links: 1359057

Description Jan Pokorný [poki] 2017-08-07 17:12:29 UTC
This idea arose on ML in relation to crm, but may be worth considering
for pcs nonetheless.  See the bottom part of:

http://oss.clusterlabs.org/pipermail/users/2017-August/006226.html

Technicalities:

1. I suppose such journal of what (logical, not necessarily 1:1, see
   below) pcs commands have been run would be dead-simple, local-only
   (otherwise there's this common risk pcs would need to come up with
   its own faul-tolerant cluster/peer network).  However, to allow for
   post-mortem entries correlation, there should be an extra field or two:
   - the originator of the command (user/pcsd), so that, for instance,
     a dedicated command (if any) can search back just through the real
     user entries
   - for the "execute-on-live-nodes in parallel", set an extra flag
     so that the journals can be correlated more easily, just looking
     at the entries like these

2. current accumulate-then-push method hides what really goes on when
   chunked (and possibly interleaved with custom sed commands and other
   out-of-band edits) and hence loses the continuity amongst the
   commands, should it be somehow recoverable;  alternative proposal
   from [bug 1359057] would, on the other hand, allow for much more
   solid expectation of what series of commands coupled together
   tightly (there could even be a checksuming incorporated into
   the "pipe protocol" to be 100% sure), hence these could be
   put into journal as an atomic block (compound command comprising
   particular pcs commands delimited with a pipe) at once, preserving
   readibility and (importantly) the intention

User-facing commands to work with such a journal can be added at later
stage, when it's clear what exactly would make sense.  I am currently
thinking more in the manual investigation intentions.

Comment 1 Tomas Jelinek 2018-01-09 11:49:24 UTC

*** This bug has been marked as a duplicate of bug 1427495 ***


Note You need to log in before you can comment on or make changes to this bug.