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

[Jehan-Guillaume de Rorthais]

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/backend/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.

>  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.

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 ?

>  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¢,