Bug 1509381 - Rebase clufter component [RHEL 7.5]
Summary: Rebase clufter component [RHEL 7.5]
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: clufter   
(Show other bugs)
Version: 7.6
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Pokorný [poki]
QA Contact: cluster-qe@redhat.com
Steven J. Levine
URL:
Whiteboard:
Keywords: Rebase
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-03 16:32 UTC by Jan Pokorný [poki]
Modified: 2018-05-14 15:03 UTC (History)
5 users (show)

Fixed In Version: clufter-0.77.0-1.el7
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
_clufter_ rebased to version 0.77.0 The _clufter_ packages have been upgraded to upstream version 0.77.0, which provides a number of bug fixes, new features, and user experience enhancements over the previous version. Among the notable updates are the following: * When using `clufter` to translate an existing configuration with the `pcs2pcscmd-needle` command in the case where the `corosync.conf` equivalent omits the `cluster_name` option (which is 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 include the `--encryption 0|1` switch when available, in order to reflect the original configuration accurately. * In any script-like output sequence such as that produced with 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 be honored by the operating system. (BZ#1381531) * The `clufter` tool now also covers some additional recently added means of configuration as facilitated with `pcs` (heuristics for a quorum device, meta attributes for top-level `bundle` resource units) when producing the sequence of configuring `pcs` commands to reflect existing configurations when applicable. For information on the capabilities of *clufter*, see the `clufter(1)` man page or the output of the "clufter -h" command. For examples of *clufter* usage, see the following Red Hat Knowledgebase article: https://access.redhat.com/articles/2810031.
Story Points: ---
Clone Of:
: 1589371 (view as bug list)
Environment:
Last Closed: 2018-04-10 18:48:04 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1009 None None None 2018-04-10 18:48 UTC

Description Jan Pokorný [poki] 2017-11-03 16:32:03 UTC
Known bugs:
- cluster_name-less corosync.conf results in broken pcs command
  arising from pcs2pcscmd
- clufter does not currently bother to warn user if the encryption
  was enabled in source corosync.conf (or, in turn, original
  cluster.conf) and then it cannot enabled because of the lack
  on pcs side -- conversely, it cannot currently emit
  "pcs cluster setup --encryption 1" in case pcs already supports
  that
- pcs vs. bundle metadata recent refresh perhaps needs to be mirrored
  in {cib,pcs}2pcscmd

Comment 1 Jan Pokorný [poki] 2017-11-03 16:34:05 UTC
s/cannot enabled/cannot be willingly enabled/

Comment 4 Jan Pokorný [poki] 2017-11-13 22:07:14 UTC
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

Comment 8 errata-xmlrpc 2018-04-10 18:48:04 UTC
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

Comment 9 Jan Pokorný [poki] 2018-04-19 16:42:49 UTC
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).

Comment 10 Jan Pokorný [poki] 2018-04-19 16:43:27 UTC
(taking [bug 1526494 comment 8] into account)


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