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.
On 4/3/2014 4:57 PM, Paul Cuzner wrote:
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.
Would a peer probe then be more of a diagnostic command ?
- ie return whether 24007 is open, perform initial handshake -
determine gluster version and report back to the admin?
This would mean that you could make intelligent decisions about
bringing nodes into the cluster from the automation platform.
------------------------------------------------------------------------
*From: *"Nagaprasad Sathyanarayana" <nsath...@redhat.com>
*To: *"James" <purplei...@gmail.com>
*Cc: *gluster-devel@nongnu.org
*Sent: *Tuesday, 1 April, 2014 6:01:42 PM
*Subject: *Re: [Gluster-devel] Introducing a new option to gluster
peer command.
On 04/01/2014 08:23 AM, James wrote:
On Mon, Mar 31, 2014 at 10:29 PM, Nagaprasad Sathyanarayana
<nsath...@redhat.com> wrote:
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.
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
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. When we give
/peer detach/ option, I think it would be natural to expect a
/peer attach/ command.
Thanks
Naga
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
