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 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". Most of the names stay under the convenient 15-character limit anyway. On Wed, 2018-03-28 at 12:40 -0500, Ken Gaillot wrote: > Hi all, > > Andrew Beekhof brought up a potential change to help with reading > Pacemaker logs. > > Currently, pacemaker daemon names are not intuitive, making it > difficult to search the system log or understand what each one does. > > The idea is to rename the daemons, with a common prefix, and a name > that better reflects the purpose. > > I think it's a great idea, but we have to consider two drawbacks: > > * I'm about to release 2.0.0-rc2, and it's late in the cycle for a > major change. But if we don't do it now, it'll probably sit on the > back > burner for a few years, as it wouldn't make sense to introduce such a > change shortly after a major bump. > > * We can change *only* the names used in the logs, which will be > simple, but give us inconsistencies with what shows up in "ps", etc. > Or > we can try to change everything -- process names, library names, API > function/structure names -- but that will impact other projects such > as > sbd, crmsh, etc., potentially causing compatibility headaches. > > What are your thoughts? Change or not? Now or later? Log tags, or > everything? > > And the fun part, what would we change them to ... > > Beekhof suggested renaming "pengine" to "cluster-planner", as an > example. > > I think a prefix indicating pacemaker specifically would be better > than > "cluster-" for grepping and intuitiveness. > > For intuitiveness, long names are better ("pacemaker-FUNCTION"). On > the > other hand, there's an argument for keeping names to 15 characters, > which is the default "ps" column width, and a reasonable limit for > log > line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used for > library names. > > Looking at other projects with server processes, most use the > traditional "d" ending (for example, "rsyslogd"). A few add "-daemon" > ("rtkit-daemon"), and others don't bother with any suffix ("gdm"). > > Here are the current names, with some example replacements: > > pacemakerd: PREFIX-launchd, PREFIX-launcher > > attrd: PREFIX-attrd, PREFIX-attributes > > cib: PREFIX-configd, PREFIX-state > > crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller > > lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner > > pengine: PREFIX-policyd, PREFIX-scheduler > > stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner > > pacemaker_remoted: PREFIX-remoted, PREFIX-remote > -- 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