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

[Jan Pokorný]

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?

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

> Most of the names stay under the convenient 15-character limit
> anyway.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180410/393b7a1b/attachment.sig>