Bug 1509381

s/cannot enabled/cannot be willingly enabled/

Regarding documentation, there has been just a single point version
since RHEL 7.4, which is clufter v0.77.0.  From the changelog in
the announcement[1], these points are of interest:

> - bug fixes
> 
>   . pcs2pcscmd-needle command would previously lead to an incorrect
>     "pcs cluster setup" command in the resulting sequence when the
>     "cluster_name" parameter in the "totem" section of the input
>     corosync configuration was not (very legitimately) specified,
>     because the name of the first given node (if present) would
>     be mistakenly used where the cluster name specification was
>     expected as it was effectively skipped in the respective syntax;
>     now an artificial name is supplied instead if need be
>     (currently, pcs cannot create nameless clusters like that)
> 
>   . all commands having sequence of pcs commands on the output,
>     hence getting post-processed (line-wrapped and generally
>     prettified) with the aim to get them human-friendly, might
>     previously suffer from some characters with special meaning
>     in shell language not being quoted (nor escaped for that matter)
>     properly (despite they might have been prior to this post-process),
>     leading to various, possibly subtle misbehaviours when executed
>     (for instance part of the intended standalone command being run in
>     the backgrounded subshell while the rest getting interpreted as
>     as a whole new, likely not fulfillable, command, if the particular
>     unquoted chunk in the case at hand contained '&' character); trivial
>     instances of this discrepancy should no longer occur, and for extra
>     confidence (or as a workaround with older versions), one can always
>     use "--noop=cmd-wrap" to suppress (tiny bit erratic) post-processing
>     (thanks to Madkiss, seconded by lge at #clusterlabs)

the two above would need to be simplified

> - feature extensions:
> 
>   . {ccs,cib,pcs}2pcscmd* commands now make use of "--encryption 0|1"
>     switch finally added to "pcs cluster setup" command, incl. dealing
>     with a hiccup of introducing that support unconditionally (0.9.158),
>     only to return back to original default of no encryption, but with
>     a possibility to enable it (0.9.159 and counting), depending
>     on the pcs versions of the target distribution

the above would surely need to be rephrased

>   . pcs2pcscmd-needle command is now aware of configured heuristics for
>     a quorum device in corosync.conf-equivalent files and able to emit
>     respective configuration commands sing pcs tool, provided that the
>     target versions of relevant packages already support that
> 
>   . {cib,pcs}2pcscmd* commands are now aware of configured meta
>     attributes for top-level "bundle" encapsulations in CIB and able
>     to emit respective configuration commands using pcs tool, provided
>     that the target versions of relevant packages already support that

those two could be joined


[1] http://oss.clusterlabs.org/pipermail/users/2017-November/006802.html

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1009

re [comment 4]:

Tidying the form, taking [1526494 comment 8] into account:

---

When using `clufter` to translate existing configuration with
`pcs2pcscmd-needle` command whereby `corosync.conf` equivalent
omits `cluster_name` option (not the case with standard `pcs`
initiated configurations), the contained `pcs cluster setup`
invocation no longer causes cluster misconfiguration with the
name of the first given node interpreted as the required cluster
name specification.  The same invocation will now be enriched
with "--encryption 0|1" switch when available, in order to
reflect the original configuration truthfully.

In any script-like output sequence such as that produced by the
`ccs2pcscmd` and `pcs2pcscmd` families of `clufter` commands,
the intended shell interpreter is now emitted in a valid form,
so that the respective commented line can finally be honored
by the operating system. (BZ#1381531)

The `clufter` tool now also covers some other recently added
means of configuration as facilitated with `pcs` (heuristics
for a quorum device, meta attributes for top-level `bundle`
encapsulations) when producing sequence of configuring `pcs`
commands to reflect existing configurations when applicable.

---

If possible, the final text should be kept in sync with
referenced counterpart for 6.10 (carefully, it's not 1:1).

(taking [bug 1526494 comment 8] into account)