Bug 1359057

Summary: [cli] pcs should provide enhanced, stackable, integrity-protecting "pcs cluster cib/cib-push" alternative
Product: Red Hat Enterprise Linux 7 Reporter: Jan Pokorný [poki] <jpokorny>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: CLOSED WONTFIX QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: cfeist, cluster-maint, cluster-qe, idevat, omular, tojeline
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1328066 Environment:
Last Closed: 2020-12-15 07:43:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1328066    
Bug Blocks: 1328078    

Description Jan Pokorný [poki] 2016-07-22 08:18:57 UTC 
This original issue:

> +++ This bug was initially created as a clone of Bug #1328066 +++
> 
> Specific use case is with clufter that was mislead in belief scenarios
> from the summary would work automatically.  Unfortunately, that's
> not the case.
> 
> There would be possibility to use the "cib" - "cib push" commands with
> unbalanced --config switch, but that lacks the consistency.
> 
> Beside, that's really just config subset of the overall CIB that's
> really needed to reason about the configuration and modify it.
> Other possible values passed as "scope" is a different story...

has been flashed out in the public mailing list:

http://oss.clusterlabs.org/pipermail/users/2016-July/003575.html
http://comments.gmane.org/gmane.comp.clustering.clusterlabs.user/2837#5

and made me think that as we are trapped in backward-compatibility
burden, it's time to crank up something fresh, well-designed,
UNIX philosophy adherent, error-prone and actually useful.
It would then be matter of time when unfortunate cib/cib-push
commands get forgotten.

* * *

Let me introduce following concept of "pcs cluster cib-pipe"
(for short, I will be using just "cib-pipe" further in the text):

1. it has two modes of operation, depending if something is
   piped into it (supports both cib-pipe <file, command | cib-pipe),
   call it PUSH mode, or not which would be referred to as PULL mode,
   the two modes are mutually exclusive

2. PUSH mode
   - push CIB at the input to live cluster
     (akin to "pcs cluster cib-push --config")
   - it should contain some additional logic such as if the root element
     is not "cib", adapt "--scope" to cibadmin respectively if still
     a valid element in the schema
   - explicit validation should be made first
   - empty or invalid input will cancel the action

3. PULL mode
   - yield CIB from live cluster (akin to "pcs cluster cib")
     and print to stdout

Ultimate goal is to be able to create chains like this:

   pcs cluster cib-pipe \
     | pcs -f- resource create dummy Dummy \
     | pcs -f- ... \
     | pcs cluster cib-pipe

Note that "-f -" would have to be extra-cased as "read from stdin,
write to stdout".
Comment 1 Jan Pokorný [poki] 2016-07-22 08:22:09 UTC 
Even better, it would be just "pcs pipe", but I would want too much,
perhaps.
Comment 2 Jan Pokorný [poki] 2016-07-27 13:01:35 UTC 
re [comment 0], 2. PUSH mode:

- actually it shoud behave as with "pcs cluster cib-push --config --wait"
  (where I've just added --wait assumption)

Rationale is that you are likely going to pipe the modifications like
this in the script where you definitely expect that one block of commands
is definitely finished before you move on further.
And it's worthwhile also in interactive use, anyway (--wait really
should generally have been a default behavior since day 1).
Comment 3 Jan Pokorný [poki] 2017-02-08 14:11:17 UTC 
See also [bug 1420298 comment 3].
Comment 4 Jan Pokorný [poki] 2017-05-02 15:14:54 UTC 
In the light of the pcs getting smarter/more sophisticated wrt.
pushing updates to cluster per [bug 1404233], that is, sending just
the difference against (still user managed! but see [bug 1441673])
baseline, the suggested idea should be updated to reflect that.

Borrowing a use case example from [comment 1]:

>   pcs cluster cib-pipe \
>     | pcs -f- resource create dummy Dummy \
>     | pcs -f- ... \
>     | pcs cluster cib-pipe

the syntax would not need to change, but the behavior would change
slightly wrt. treating the XMLs being piped:

- a dedicated XML processing instruction (PI) at the very head
  would encode the temporary "original" file (first process
  in the pipeline would hold a lock on that for good measure),
  e.g. <?pcs-original file="/tmp/pcs-1001/s23Fsga.tmp"?>

- such an annotation would be injected by the initial "pull"
  process and preserved by all the other ones

- last process (~ cib-pipe) would then check if the PI is
  present and if positive, would adapt the push process
  akin to "pcs cluster cib-push NEW diff-against=OLD"
Comment 5 Jan Pokorný [poki] 2017-06-14 20:19:21 UTC 
BTW. accidental gentle reminder how unwieldy the original
fetch-change-push syntax for pcs commands is:

http://oss.clusterlabs.org/pipermail/users/2017-June/005879.html
Comment 6 Jan Pokorný [poki] 2017-08-07 17:28:01 UTC 
Based on [bug 1479009 comment 0], it might be preferable to have
checksumming (accompanied with throughout-the-chain accumulated
prior commands) a part of the "pipe protocol" coherently tighting
the chain of pcs commands up so as to attest intergrity of the
end-to-end processing and hence allowing to treat that group of
commands as atomic block for the purpose of journaling.
Comment 7 Jan Pokorný [poki] 2018-06-15 10:28:46 UTC 
Note that using this one-way logically interconnected composites
as a means to stack several operations prior to firing them at once
has also the advantage of amortizing some actions that suffice to be
performed just once -- like sanity checking the target cluster stack
is compatible with what pcs can indeed control (cf. See Also).
Comment 8 Jan Pokorný [poki] 2018-08-06 16:30:43 UTC 
See bottom part [bug 1488044 comment 17] for why maintaining integrity
in the pull-push round-trip ("checksumming" per [comment 6]) may be
of importance -- here to prevent keen double-checking (e.g. of
crm_feature_set within the target cluster) where it can be safely
skipped.
Comment 10 RHEL Program Management 2020-12-15 07:43:12 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.