[ClusterLabs] Pacemaker 2.0.3-rc3 now available

Ken Gaillot kgaillot at redhat.com
Thu Nov 14 11:16:01 EST 2019


On Thu, 2019-11-14 at 14:54 +0100, Jan Pokorný wrote:
> 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?

Console is crm_mon's interactive curses interface

> 
>   - 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.
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list