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

[Ken Gaillot]

Based on the list discussion and feedback I could coax out of others, I
will change the Pacemaker daemon names, including the log tags, for
2.0.0-rc3.

I will add symlinks for the old names, to allow help/version/metadata
calls in user scripts and higher-level tools to continue working during
a transitional time. (Even if we update all known tools, we need to
keep compatibility with existing versions for a good while.)

I won't change the systemd unit file names or API library names, since
they aren't one-to-one with the daemons, and will have a bigger impact
on client apps.

Here's my current plan:

Old name          New name
--------          --------
pacemakerd        pacemakerd
attrd             pacemaker-attrd
cib               pacemaker-confd
crmd              pacemaker-controld
lrmd              pacemaker-execd
pengine           pacemaker-schedulerd
stonithd          pacemaker-fenced
pacemaker_remoted pacemaker-remoted

I had planned to use the "pcmk-" prefix, but I kept thinking about the
goal of making things more intuitive for novice users, and a novice
user's first instinct will be to search the logs for "pacemaker". Most
of the names stay under the convenient 15-character limit anyway.

On Wed, 2018-03-28 at 12:40 -0500, Ken Gaillot 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? Now or later? Log tags, or
> everything?
> 
> 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.
> 
> 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
> 
>  attrd: PREFIX-attrd, PREFIX-attributes
> 
>  cib: PREFIX-configd, PREFIX-state
> 
>  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
> 
>  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
> 
>  pengine: PREFIX-policyd, PREFIX-scheduler
> 
>  stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
> 
>  pacemaker_remoted: PREFIX-remoted, PREFIX-remote
> 
-- 
Ken Gaillot <kgaillot at redhat.com>