On 04/11/2018 01:14 AM, Andrew Beekhof wrote: > > > On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot <[email protected] > <mailto:[email protected]>> 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] <mailto:[email protected]>> > 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 <[email protected] <mailto:[email protected]>> > _______________________________________________ > Users mailing list: [email protected] > <mailto:[email protected]> > 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: [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
_______________________________________________ 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
