<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>