[ClusterLabs] Pacemaker 2.0.3-rc3 now available

Jan Pokorný jpokorny at redhat.com
Thu Nov 14 08:54:01 EST 2019


On 13/11/19 17:30 -0600, Ken Gaillot wrote:
> This fixes some more minor regressions in crm_mon introduced in rc1.
> Additionally, after feedback from this list, the new output format
> options were shortened. The help is now:
> 
> Output Options:
>   --output-as=FORMAT       Specify output format as one of: console (default), html, text, xml
>   --output-to=DEST         Specify file name for output (or "-" for stdout)
>   --html-cgi               Add CGI headers (requires --output-as=html)
>   --html-stylesheet=URI    Link to an external stylesheet (requires --output-as=html)
>   --html-title=TITLE       Specify a page title (requires --output-as=html)
>   --text-fancy             Use more highly formatted output (requires --output-as=text)

Wearing the random user§s shoes, this leaves more questions behind
than it answers:

* what's the difference between "console" and "text", is any of these
  considered more stable in time than the other?

  - do I understand it correctly that the password, when needed for
    remote CIB access, will only be prompted for "console"?

* will --text-fancy work work with --output-as-console?
  the wording seems to suggest it won't

Doubtless explorability seems to be put on the backburner in
favour of straightforward wiring front-end to convoluted logic
in the command's back-end rather than going backwards, from
simple-to-understand behaviours down to the logic itself.

E.g., it may be easier to follow when there is
a documented equivalence of "--output-as=console" and
"--output-as=text --text-password-prompt-allowed",
assuming a new text-output specific switch that is
not enabled by default otherwise.

> A longstanding display issue in crm_mon has been fixed. The disabled
> and blocked resources count was previously incorrect. The new, accurate
> count changes the text from "resources" to "resource instances",
> because individual instances of a cloned or bundled resource can be
> blocked. For example, if you have one regular resource, and a cloned
> resource running on three nodes, it would count as 4 resource
> instances.
> 
> A longstanding pain point in the logs has been improved. Whenever the
> scheduler processes resource history, it logs a warning for any
> failures it finds, regardless of whether they are new or old, which can
> confuse anyone reading the logs. Now, the log will contain the time of
> the failure, so it's obvious whether you're seeing the same event or
> not.

Just curious, how sensitive is this to time shifts, e.g. timezone
related?  If it is (human/machine can be unable to match the same event
reported back then and now in a straightforward way, for say time zone
transition in between), considering some sort of rather unique
identifier would be a more systemic approach for an event matching
in an invariant manner, but then would we need some notion of
monotonous cluster-wide sequence ordering?

> The log will also contain the exit reason if one was provided by the
> resource agent, for easier troubleshooting.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20191114/d440361a/attachment.sig>


More information about the Users mailing list