Bug 1359057 - [cli] pcs should provide enhanced, stackable, integrity-protecting "pcs cluster cib/cib-push" alternative
Summary: [cli] pcs should provide enhanced, stackable, integrity-protecting "pcs clust...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
Depends On: 1328066
Blocks: 1328078
TreeView+ depends on / blocked
Reported: 2016-07-22 08:18 UTC by Jan Pokorný [poki]
Modified: 2020-12-15 07:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1328066
Last Closed: 2020-12-15 07:43:12 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1404233 0 urgent CLOSED Make pcs avoid a full CIB replacement when possible 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1420298 0 medium CLOSED "pcs resource delete" overhaul 2022-07-12 15:36:21 UTC
Red Hat Bugzilla 1479009 0 unspecified CLOSED [RFE] consider timestamped journal of the past pcs commands 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1488044 0 medium CLOSED do not push the CIB as a diff if 'crm_feature_set' is <= 3.0.8 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1591252 0 unspecified CLOSED [usage sanity] The expectations about the administered stack should be clear and enforced 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1591258 1 None None None 2021-01-20 06:05:38 UTC

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:


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,

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:


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

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.

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