<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot <span dir="ltr"><<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais wrote:<br>
> On Tue, 10 Apr 2018 00:54:01 +0200<br>
> Jan Pokorný <<a href="mailto:jpokorny@redhat.com">jpokorny@redhat.com</a>> wrote:<br>
><br>
> > On 09/04/18 12:10 -0500, Ken Gaillot wrote:<br>
> > > Based on the list discussion and feedback I could coax out of<br>
> > > others, I<br>
> > > will change the Pacemaker daemon names, including the log tags,<br>
> > > for<br>
> > > 2.0.0-rc3.<br>
> > ><br>
> > > I will add symlinks for the old names, to allow<br>
> > > help/version/metadata<br>
> > > calls in user scripts and higher-level tools to continue working<br>
> > > during<br>
> > > a transitional time. (Even if we update all known tools, we need<br>
> > > to<br>
> > > keep compatibility with existing versions for a good while.)<br>
> > ><br>
> > > I won't change the systemd unit file names or API library names,<br>
> > > since<br>
> > > they aren't one-to-one with the daemons, and will have a bigger<br>
> > > impact<br>
> > > on client apps.<br>
> > ><br>
> > > Here's my current plan:<br>
> > ><br>
> > > Old name          New name<br>
> > > --------          --------<br>
> > > pacemakerd        pacemakerd<br>
> > > attrd             pacemaker-<wbr>attrd<br>
> > > cib               pacemaker-<wbr>confd  <br>
> ><br>
> > Let's restate it: do we indeed want to reinforce a misnomer that<br>
> > CIB<br>
> > is (user) configuration only?<br>
><br>
> Agree. FWIW, +1 for the "Infod" suggestion.<br>
<br>
</div></div>I'm not opposed to it, but no option suggested so far intuitively<br>
covers what the cib does (including "cib"). All the daemons maintain<br>
information of some sort for querying and setting -- attrd maintains<br>
node attributes, stonithd maintains fence history, lrmd maintains a<br>
list of registered resources, etc.<br>
<br>
-confd, -cfgd, or -configd would emphasize the configuration aspect of<br>
cib's workload, at the cost of hiding the dynamic status aspect.<br></blockquote><div><br></div><div>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.</div><div>i've toyed with the idea in the past to alleviate some of the performance issues</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-infod, -datad, or -stated (or cib) would emphasize the broadness of<br>
cib's workload, at the cost of being vague and including aspects of<br>
other daemons' responsibilities.<br>
<br>
-iod would emphasize cib's role as a disk I/O abstraction layer, at the<br>
 cost of downplaying the more essential configuration+status roles.<br>
<br>
Given all that, I'm leaning to -confd because configuration management<br>
is the cib's primary responsibility. </blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The CIB stored on disk is entirely<br>
configuration (status is only in-memory), so it seems most intuitive to<br>
me. Keep in mind that the primary purpose of this renaming is to make<br>
the log files easier to read, so picture the name in front of a typical<br>
CIB log message (also considering that "info" is a log severity).<br>
<br>
But if there's a consensus otherwise, I'm willing to change it.<br>
<span class="im HOEnZb"><br>
><br>
> > > crmd              pacemaker-<wbr>controld<br>
> > > lrmd              pacemaker-<wbr>execd<br>
> > > pengine           pacemaker-<wbr>schedulerd<br>
> > > stonithd          pacemaker-<wbr>fenced<br>
> > > pacemaker_remoted pacemaker-remoted<br>
> > ><br>
> > > I had planned to use the "pcmk-" prefix, but I kept thinking<br>
> > > about the<br>
> > > goal of making things more intuitive for novice users, and a<br>
> > > novice<br>
> > > user's first instinct will be to search the logs for<br>
> > > "pacemaker"  <br>
> ><br>
> > journalctl -u pacemaker?<br>
> ><br>
> > We could also ship an example syslog configuration that aggegrates<br>
> > messages from enumerated programs (that we know and user may not<br>
> > offhand)<br>
> > into a dedicated file (well, this would be quite redundant to<br>
> > native<br>
> > logging into the file).<br>
> ><br>
> > IOW, I wouldn't worry that much.<br>
><br>
> +1<br>
><br>
> My 2¢...<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div></div>