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)
pgpoEZgUpnkkn.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/