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

[Jehan-Guillaume de Rorthais]

On Tue, 10 Apr 2018 18:08:55 +0200
Jan Pokorný <jpokorny at redhat.com> wrote:

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

This makes me think of DBus now :)

...This kind of makes sense though, as it gather and provide data from
multiple various process ;)