[ClusterLabs] Possible idea for 2.0.0: renaming the Pacemaker daemons

[Ken Gaillot]

On Wed, 2018-03-28 at 21:41 +0200, Jehan-Guillaume de Rorthais wrote:
> On Wed, 28 Mar 2018 12:40:25 -0500
> Ken Gaillot <kgaillot at redhat.com> wrote:
> 
> > Hi all,
> > 
> > Andrew Beekhof brought up a potential change to help with reading
> > Pacemaker logs.
> > 
> > Currently, pacemaker daemon names are not intuitive, making it
> > difficult to search the system log or understand what each one
> > does.
> > 
> > The idea is to rename the daemons, with a common prefix, and a name
> > that better reflects the purpose.
> > 
> > I think it's a great idea, but we have to consider two drawbacks:
> > 
> > * I'm about to release 2.0.0-rc2, and it's late in the cycle for a
> > major change. But if we don't do it now, it'll probably sit on the
> > back
> > burner for a few years, as it wouldn't make sense to introduce such
> > a
> > change shortly after a major bump.
> > 
> > * We can change *only* the names used in the logs, which will be
> > simple, but give us inconsistencies with what shows up in "ps",
> > etc. Or
> > we can try to change everything -- process names, library names,
> > API
> > function/structure names -- but that will impact other projects
> > such as
> > sbd, crmsh, etc., potentially causing compatibility headaches.
> > 
> > What are your thoughts? Change or not? 
> 
> change
> 
> > Now or later?
> 
> I'm not sure how much work it involves during rc time... But I would
> pick now
> if possible.
> 
> > Log tags, or everything?
> 
> Everything.
> 
> I'm from the PostgreSQL galaxy. In this galaxy, parameter
> "update_process_title" controls if PostgreSQL should set human
> readable process
> title and is "on" by default. In ps, it gives:
> 
>   ioguix at firost:~$ ps f -o cmd -C postmaster
>   CMD
>   postmaster -D /home/ioguix/var/lib/pgsql/96
>    \_ postgres: checkpointer process   
>    \_ postgres: writer process   
>    \_ postgres: wal writer process   
>    \_ postgres: autovacuum launcher process   
>    \_ postgres: stats collector process   
> 
> Some process might even add some useful information about their
> status, eg.:
> current replication status and location (process wal receiver/sender)
> or last
> WAL archived (process archiver).
> 
> In source code, it boils down to this function:
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/back
> end/utils/misc/ps_status.c;h=5742de0802a54e38a2c2e3cfa8e8f445b6822883
> ;hb=65c6b53991e1c56f6a0700ae26928962ddf2b9fe#l321
> 
> > And the fun part, what would we change them to ...
> > 
> > Beekhof suggested renaming "pengine" to "cluster-planner", as an
> > example.
> > 
> > I think a prefix indicating pacemaker specifically would be better
> > than
> > "cluster-" for grepping and intuitiveness.
> > 
> > For intuitiveness, long names are better ("pacemaker-FUNCTION"). On
> > the
> > other hand, there's an argument for keeping names to 15 characters,
> > which is the default "ps" column width, and a reasonable limit for
> > log
> > line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used
> > for
> > library names.
> 
> "pcmk-*" sounds better to me. "cluster" has so many different
> definiion in
> people mind...
> 
> > Looking at other projects with server processes, most use the
> > traditional "d" ending (for example, "rsyslogd"). A few add "-
> > daemon"
> > ("rtkit-daemon"), and others don't bother with any suffix ("gdm").
> > 
> > Here are the current names, with some example replacements:
> > 
> >  pacemakerd: PREFIX-launchd, PREFIX-launcher
> 
> pacemakerd, alone, sounds perfectly fine to me.

Agreed -- but the argument against it is to allow something like "grep
pcmk /var/log/messages" to get everything.

> >  attrd: PREFIX-attrd, PREFIX-attributes
> 
> PREFIX-attributes
> 
> >  cib: PREFIX-configd, PREFIX-state
> 
> Tricky...It deals with both config and state...
> 
> By the way, why in the first place the CIB messages must be in the
> log file?
> Filling logs with XML diffs resulting from other actions already
> logged earlier
> sounds like duplicated informations.

They are kept out of the syslog, which is where most users are expected
to look. They are in the detail log, which is for more advanced
troubleshooting.

The detail log messages are useful mainly because CIB changes can come
from external sources, not just cluster daemons, and also to easily see
the XML syntax was as expected.

> I suppose most of the CIB logging messages could be set in debug
> level or
> replaced by a simple "cib updated with new {setup|status}"?
>
> >  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
> 
> PREFIX-controld
> 
> >  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
> 
> PREFIX-executord? PREFIX-execd ?

-execd makes sense

> >  pengine: PREFIX-policyd, PREFIX-scheduler
> 
> PREFIX-schedulerd
> 
> > stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
> 
> I always disliked the STONITH acronym. For the same reasons, I
> dislike "executioner" as well. Moreover, some people might think it
> actually
> "executes" some process in the sense of "running".
> 
> I would definitely vote for PREFIX-fenced
> 
> >  pacemaker_remoted: PREFIX-remoted, PREFIX-remote
> 
> PREFIX-remoted
> 
> 
> My 2¢,
-- 
Ken Gaillot <kgaillot at redhat.com>