[ClusterLabs] low-cost ways to make Pacemaker more usable?

[Adam Spiers]

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 ;-)