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

[Ken Gaillot]

On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais wrote:
> On Tue, 10 Apr 2018 00:54:01 +0200
> Jan Pokorný <jpokorny at redhat.com> wrote:
> 
> > On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> > > 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  
> > 
> > Let's restate it: do we indeed want to reinforce a misnomer that
> > CIB
> > is (user) configuration only?
> 
> Agree. FWIW, +1 for the "Infod" suggestion.

I'm not opposed to it, but no option suggested so far intuitively
covers what the cib does (including "cib"). All the daemons maintain
information of some sort for querying and setting -- attrd maintains
node attributes, stonithd maintains fence history, lrmd maintains a
list of registered resources, etc.

-confd, -cfgd, or -configd would emphasize the configuration aspect of
cib's workload, at the cost of hiding the dynamic status aspect.

-infod, -datad, or -stated (or cib) would emphasize the broadness of
cib's workload, at the cost of being vague and including aspects of
other daemons' responsibilities.

-iod would emphasize cib's role as a disk I/O abstraction layer, at the
 cost of downplaying the more essential configuration+status roles.

Given all that, I'm leaning to -confd because configuration management
is the cib's primary responsibility. The CIB stored on disk is entirely
configuration (status is only in-memory), so it seems most intuitive to
me. Keep in mind that the primary purpose of this renaming is to make
the log files easier to read, so picture the name in front of a typical
CIB log message (also considering that "info" is a log severity).

But if there's a consensus otherwise, I'm willing to change it.

> 
> > > 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"  
> > 
> > journalctl -u pacemaker?
> > 
> > We could also ship an example syslog configuration that aggegrates
> > messages from enumerated programs (that we know and user may not
> > offhand)
> > into a dedicated file (well, this would be quite redundant to
> > native
> > logging into the file).
> > 
> > IOW, I wouldn't worry that much.
> 
> +1
> 
> My 2¢...
-- 
Ken Gaillot <kgaillot at redhat.com>