<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/11/2018 01:14 AM, Andrew Beekhof
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+YPjkhq0PkN6vrugPjdJbrcUpxgONX0XDk596KME9CLztSrEQ@mail.gmail.com">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
</div>
</blockquote>
<br>
And maybe even a 3rd one for attributes/key-storage - picking up the
idea floating<br>
around in this thread as well.<br>
<br>
<blockquote type="cite"
cite="mid:CA+YPjkhq0PkN6vrugPjdJbrcUpxgONX0XDk596KME9CLztSrEQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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"
moz-do-not-send="true">kgaillot@redhat.com</a>><br>
</font></span>
<div class="HOEnZb">
<div class="h5">______________________________<wbr>_________________<br>
Users mailing list: <a
href="mailto:Users@clusterlabs.org"
moz-do-not-send="true">Users@clusterlabs.org</a><br>
<a
href="https://lists.clusterlabs.org/mailman/listinfo/users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://www.clusterlabs.org</a><br>
Getting started: <a
href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://bugs.clusterlabs.org</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list: <a class="moz-txt-link-abbreviated" href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
Project Home: <a class="moz-txt-link-freetext" href="http://www.clusterlabs.org">http://www.clusterlabs.org</a>
Getting started: <a class="moz-txt-link-freetext" href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a>
Bugs: <a class="moz-txt-link-freetext" href="http://bugs.clusterlabs.org">http://bugs.clusterlabs.org</a>
</pre>
</blockquote>
<br>
</body>
</html>