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".
Even better, it would be just "pcs pipe", but I would want too much,
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).
See also [bug 1420298 comment 3].
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"
BTW. accidental gentle reminder how unwieldy the original
fetch-change-push syntax for pcs commands is:
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.
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).
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