|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:||pcs||Assignee:||Tomas Jelinek <tojeline>|
|Status:||NEW ---||QA Contact:||cluster-qe <cluster-qe>|
|Version:||7.2||CC:||cfeist, cluster-maint, cluster-qe, idevat, omular, tojeline|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1328066|
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 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.