Ken Gaillot <kgail...@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 ;-)
_______________________________________________
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
