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ý <[email protected]> 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

Attachment: pgp1VVL12pD3k.pgp
Description: PGP signature

_______________________________________________
Users mailing list: [email protected]
https://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Reply via email to