[Gluster-devel] Introducing a new option to gluster peer command.

[Giuseppe Ragusa]

Well, "peer ping" since we are giving way to imagination... :)

Date: Sun, 6 Apr 2014 15:42:03 -0400
From: pcuzner at redhat.com
To: jayunit100 at gmail.com
CC: gluster-devel at nongnu.org
Subject: Re: [Gluster-devel] Introducing a new option to gluster peer command.


Sounds like a great idea.

Although, peer sniff .... Really :)

What about "peer detect"?



From: "Jay Vyas" <jayunit100 at gmail.com>
To: "Harshavardhana" <harsha at harshavardhana.net>
Cc: "Paul Cuzner" <pcuzner at redhat.com>, "Gluster Devel" <gluster-devel at nongnu.org>
Sent: Friday, 4 April, 2014 3:58:32 PM
Subject: Re: [Gluster-devel] Introducing a new option to gluster peer command.

can i suggest that instead, we  keep peer probe as is, and rewrite it to call two subcommands 

- peer sniff
- peer attach

That way users that want advanced peer sniffing can do so, without breaking backwards compatibility




On Thu, Apr 3, 2014 at 9:22 PM, Harshavardhana <harsha at harshavardhana.net> wrote:
+1 to Paul's idea - it sounds more friendly from Admin point of view -
 also provides consistency with naming schemes.

 On Thu, Apr 3, 2014 at 4:57 PM, Paul Cuzner <pcuzner at redhat.com> 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" <nsathyan at redhat.com>
 > To: "James" <purpleidea at gmail.com>
 > Cc: gluster-devel at 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
 > <nsathyan at 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 at nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/gluster-devel
 >
 >
 >
 > _______________________________________________
 > Gluster-devel mailing list
 > Gluster-devel at nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/gluster-devel
 >
 
 
 
--
 Religious confuse piety with mere ritual, the virtuous confuse
 regulation with outcomes
 
 _______________________________________________
 Gluster-devel mailing list
 Gluster-devel at nongnu.org
 https://lists.nongnu.org/mailman/listinfo/gluster-devel


-- 
Jay Vyas
http://jayunit100.blogspot.com

_______________________________________________
Gluster-devel mailing list
Gluster-devel at nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140406/97f145a5/attachment-0001.html>