gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Giuseppe Ragusa
Subject: Re: [Gluster-devel] Introducing a new option to gluster peer command.
Date: Sun, 6 Apr 2014 22:04:07 +0200

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


Date: Sun, 6 Apr 2014 15:42:03 -0400
From: address@hidden
To: address@hidden
CC: address@hidden
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" <address@hidden>
To: "Harshavardhana" <address@hidden>
Cc: "Paul Cuzner" <address@hidden>, "Gluster Devel" <address@hidden>
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 <address@hidden> 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 <address@hidden> 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" <address@hidden>
> To: "James" <address@hidden>
> Cc: address@hidden
> 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
> <address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>



--
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes

_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel



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


_______________________________________________ Gluster-devel mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/gluster-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]