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

[Andrew Beekhof]

On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot <kgaillot at redhat.com> 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:
> > > > 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?
> >
> > 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.
>

you know... I wouldn't be opposed to running two copies (one for config,
one for status) and having the crmd combine the two before sending to the
PE.
i've toyed with the idea in the past to alleviate some of the performance
issues


>
> -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.
>
> Given all that, I'm leaning to -confd because configuration management
> is the cib's primary responsibility.


+1


> 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.
>
> >
> > > > 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.
> >
> > +1
> >
> > My 2¢...
> --
> Ken Gaillot <kgaillot at redhat.com>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180411/93ed6b14/attachment-0002.html>