[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
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Alias=
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.

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


More information about the Users mailing list