Sounds like a great idea. Although, peer sniff .... Really :)
What about "peer detect"? ----- Original Message ----- > From: "Jay Vyas" <jayunit...@gmail.com> > To: "Harshavardhana" <har...@harshavardhana.net> > Cc: "Paul Cuzner" <pcuz...@redhat.com>, "Gluster Devel" > <gluster-devel@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 < har...@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 < pcuz...@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" < 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 > > > > > > > -- > > > Religious confuse piety with mere ritual, the virtuous confuse > > > regulation with outcomes > > > _______________________________________________ > > > Gluster-devel mailing list > > > Gluster-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/gluster-devel > > -- > Jay Vyas > http://jayunit100.blogspot.com
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
