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

Jan Pokorný jpokorny at redhat.com
Tue Apr 10 12:08:55 EDT 2018

On 10/04/18 09:42 -0500, Ken Gaillot wrote:
> 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:
>>>> 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.

Regarding systemd, purely technical possibility is to exercise
that seems only helpfull if we would want to make pacemaker vs. pcmk
compatibility affordable in the opposite direction than what is
suggested below: if someone accidentally passes "pcmk" (under some
impression from "pcmk-X" daemon spotted somewhere) as a service
identifier instead of established "pacemaker".

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

Getting out of ideas: -datahubd.

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

-------------- 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/2a0541a3/attachment-0002.sig>

More information about the Users mailing list