<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Targeted for 4.0? Scripts are already written with the expectation
    that the probe command works a certain way and changes to the cli
    will break that compatibility. Major version changes, at least, do
    come with a certain level of backward compatibility loss.<br>
    <br>
    <div class="moz-cite-prefix">On 4/3/2014 4:57 PM, Paul Cuzner wrote:<br>
    </div>
    <blockquote
      cite="mid:1744908433.1216719.1396569467711.JavaMail.zimbra@redhat.com"
      type="cite">
      <div style="font-family: lucida console,sans-serif; font-size:
        12pt; color: #000000">
        <div><br>
        </div>
        <div>I like the idea of making the CLI more semantically
          correct. ie to drop a node from a cluster we use the term
          detach, so to add a node it should be attach.<br>
        </div>
        <div><br>
        </div>
        <div>Would a peer probe then be more of a diagnostic command ? <br>
        </div>
        <div>- ie return whether 24007 is open, perform initial
          handshake - determine gluster version and report back to the
          admin?<br>
        </div>
        <div><br>
        </div>
        <div>This would mean that you could make intelligent decisions
          about bringing nodes into the cluster from the automation
          platform.<br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <hr id="zwchr">
        <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
          </b>"Nagaprasad Sathyanarayana" <a class="moz-txt-link-rfc2396E" href="mailto:nsathyan@redhat.com">&lt;nsathyan@redhat.com&gt;</a><br>
          <b>To: </b>"James" <a class="moz-txt-link-rfc2396E" href="mailto:purpleidea@gmail.com">&lt;purpleidea@gmail.com&gt;</a><br>
          <b>Cc: </b><a class="moz-txt-link-abbreviated" href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a><br>
          <b>Sent: </b>Tuesday, 1 April, 2014 6:01:42 PM<br>
          <b>Subject: </b>Re: [Gluster-devel] Introducing a new option
          to gluster peer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;command.<br>
          <div><br>
          </div>
          <div class="moz-cite-prefix">On 04/01/2014 08:23 AM, James
            wrote:<br>
          </div>
          <blockquote
cite="mid:CADCaTgrSURfRbcCo7JGxsk9jQr11gcH__-BW9i0OsnqSzFna7w@mail.gmail.com">
            <pre>On Mon, Mar 31, 2014 at 10:29 PM, Nagaprasad Sathyanarayana
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:nsathyan@redhat.com" target="_blank">&lt;nsathyan@redhat.com&gt;</a> wrote:
</pre>
            <blockquote>
              <pre>In the current design, gluster peer probe does the job of both probing the
server and adding it to trusted pool. Once the server is added to trusted
pool, it can be detached usingpeer detach command.

Wondering if it makes sense to bring in gluster peer attach command to add
the server to trusted pool. The peer probe command will only prove the
server mentioned and tells if it is reachable. It can also be enhanced to do
some diagnostics such as probing specific ports.
</pre>
            </blockquote>
            <pre>Do I understand correctly:

gluster peer attach would attach the probing server into the pool it
is probing, correct?
If so, and if it is already a member of a pool, could you join two
different pools together?
I don't know what the gluster internals implications are, but as long
as I understand this correctly, then I think it would benefit the
management side of glusterfs.

It would certainly make peering more decentralized, as long as double
peering or running a simultaneous peer attach and peer probe don't
cause issues. This last point is very important :)


Cheers,
James
</pre>
          </blockquote>
          The "gluster peer attach" should work the same way as existing
          "gluster peer probe". The new "gluster peer probe" shall only
          probe the peer and not add it to the trusted pool.&nbsp; When we
          give <i>peer detach</i> option, I think it would be natural
          to expect a <i>peer attach</i> command.<br>
          <br>
          Thanks<br>
          Naga<br>
          <br>
          _______________________________________________<br>
          Gluster-devel mailing list<br>
          <a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
          <a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
        </blockquote>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a>
<a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>