Bug 1479009 - [RFE] consider timestamped journal of the past pcs commands
[RFE] consider timestamped journal of the past pcs commands
Status: CLOSED DUPLICATE of bug 1427495
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Tomas Jelinek
cluster-qe@redhat.com
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-07 13:12 EDT by Jan Pokorný
Modified: 2018-01-09 06:49 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-01-09 06:49:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pokorný 2017-08-07 13:12:29 EDT
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 06:49:24 EST

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