[ClusterLabs] low-cost ways to make Pacemaker more usable?
Adam Spiers
aspiers at suse.com
Thu Dec 7 17:12:00 EST 2017
Ken Gaillot <kgaillot at redhat.com> wrote:
>On Thu, 2017-12-07 at 17:15 +0000, Adam Spiers wrote:
>>For example, making a few of the most crucial existing log messages
>>less cryptic could maybe go a long way. Or if "dumbing down" log
>>messages would make life harder for developers who are familiar
>>with Pacemaker internals and need to be able to track all the gory
>>details, recognise the fact that the kind of logs which developers
>>and users need to read are vastly different, and consequently
>>provide a way of distinguishing between the two kinds. Making all
>>developer logs DEBUG level and non-developer other levels might be
>>one way, but there are probably better approaches (e.g. tag all
>>developer logs with a certain string which can be filtered out).
>
>You're late to the party on this one :)
>
>We do try to keep all messages of interest to novice users at the
>critical-to-notice levels (which go to syslog by default), messages of
>interest to more advanced users at the info level and to developers at
>the debug-to-trace levels (which go to pacemaker.log by default).
>
>There was a big push a few releases back to improve the wording of the
>most user-visible log messages. You should have seen them before. ;)
>
>In a 2015 release (libqb + pacemaker), we added support for a single
>message to go into both syslog and pacemaker.log with different levels
>of detail. The syslog message has plain English for users, and the
>pacemaker.log message has added debugging information tacked onto the
>end. For an example, see the pacemakerd "Starting Pacemaker" message in
>each log.
Hrm, I hadn't noticed that - I wonder if it's because I mainly
work with enterprise products on a long lifecycle, so maybe I didn't
experience that release yet ...
>This is definitely ongoing, and it would be really helpful to have
>examples of particular messages of how they are now vs what they should
>say.
OK, I'll bear that in mind.
>>Another simple change would be to adopt a policy that rather than
>>sharing information on this list in response to questions which
>>arise,
>>add the answers to the documentation and then just give a short reply
>>to the list saying "here's the link to the documentation I just
>>updated". I'm sure that the archives of this list are an absolute
>>gold mine of useful information, but list archives make for really
>>poor documentation ...
>
>Agreed in principle, but again it goes back to time. Better a mailing
>list post than something at the end of the to-do list.
Absolutely; I wasn't suggesting collecting yet more to-do items for
later.
>(Wiki edits don't take much more time than mailing lists, so I could
>see taking more advantage of that.)
Yep, that's the clearer version of what I was trying to say ;-)
More information about the Users
mailing list