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ý <jpoko...@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. -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. 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 <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@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