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

[Klaus Wenninger]

On 04/11/2018 01:14 AM, Andrew Beekhof wrote:
>
>
> On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot <kgaillot at redhat.com
> <mailto: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 <mailto: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

And maybe even a 3rd one for attributes/key-storage - picking up the
idea floating
around in this thread as well.

>  
>
>
>     -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 <mailto:kgaillot at redhat.com>>
>     _______________________________________________
>     Users mailing list: Users at clusterlabs.org
>     <mailto:Users at clusterlabs.org>
>     https://lists.clusterlabs.org/mailman/listinfo/users
>     <https://lists.clusterlabs.org/mailman/listinfo/users>
>
>     Project Home: http://www.clusterlabs.org
>     Getting started:
>     http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>     <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf>
>     Bugs: http://bugs.clusterlabs.org
>
>
>
>
> _______________________________________________
> 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/a3faa5f9/attachment.html>