<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<pre class="moz-signature" cols="72">regards
Aravinda</pre>
<div class="moz-cite-prefix">On Tuesday 23 August 2016 09:32 PM,
Pranith Kumar Karampuri wrote:<br>
</div>
<blockquote
cite="mid:CAOgeEnas+zMsWwzs30JF4tEJwVcOM18qmFi7zVcsuMWUpd5J=w@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 23, 2016 at 9:27 PM,
Aravinda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Today I
discussed about the topic with Rajesh, Avra and Kotresh.
Summary as below<br>
<br>
- Instead of exposing eventsd to external world why not
expose a Glusterd RPC for gf_event, Since Glusterd already
has logic for backup volfile server.<br>
- Gluster Clients to Glusterd using RPC, Glusterd will
send message to local eventsd.<br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Any suggestions for this approach?<br>
</blockquote>
<div><br>
</div>
<div>If I remember correctly this is something we considered
before we finalized on exposing eventsd. I think the
reason was that this approach takes two hops which we
didn't like in the discussion at the time. Did any other
parameter change for reconsidering this approach?<br>
</div>
</div>
</div>
</div>
</blockquote>
- No extra auth required other than existing glusterd communication<br>
- Backup volfile server for sending message to other glusterd of
server if one server is down<br>
- Events traffic is not heavy two hops may be acceptable(?)<br>
<br>
<blockquote
cite="mid:CAOgeEnas+zMsWwzs30JF4tEJwVcOM18qmFi7zVcsuMWUpd5J=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<span class="HOEnZb"><font color="#888888"><br>
Aravinda</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On Thursday 04 August 2016 11:04 AM, Aravinda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
Aravinda<br>
<br>
On 08/03/2016 09:19 PM, Vijay Bellur wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/02/2016 11:24 AM, Pranith Kumar Karampuri
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<br>
<br>
On Tue, Aug 2, 2016 at 8:21 PM, Vijay Bellur
<<a moz-do-not-send="true"
href="mailto:vbellur@redhat.com"
target="_blank">vbellur@redhat.com</a><br>
<mailto:<a moz-do-not-send="true"
href="mailto:vbellur@redhat.com"
target="_blank">vbellur@redhat.com</a>>>
wrote:<br>
<br>
On 08/02/2016 07:27 AM, Aravinda wrote:<br>
<br>
Hi,<br>
<br>
As many of you aware, Gluster Eventing
feature is available in<br>
Master.<br>
To add support to listen to the Events
from GlusterFS Clients<br>
following<br>
changes are identified<br>
<br>
- Change in Eventsd to listen to tcp
socket instead of Unix domain<br>
socket. This enables Client to send
message to Eventsd running in<br>
Storage node.<br>
- On Client connection, share Port and
Token details with Xdata<br>
- Client gf_event will connect to this
port and pushes the<br>
event(Includes Token)<br>
- Eventsd validates Token, publishes
events only if Token is valid.<br>
<br>
<br>
Is there a lifetime/renewal associated with
this token? Are there<br>
more details on how token management is
being done? Sorry if these<br>
are repeat questions as I might have missed
something along the<br>
review trail!<br>
<br>
<br>
At least in the discussion it didn't seem like
we needed any new tokens<br>
once it is generated. Do you have any usecase?<br>
<br>
</blockquote>
<br>
No specific usecase right now but I am interested
in understanding more details about token
lifecycle management. Are we planning to use the
same token infrastructure described in
Authentication section of [1]?<br>
</blockquote>
If we use the same token as in REST API then we can
expire the tokens easily without the overhead of
maintaining the token state in node. If we expire
tokens then Clients have to get new tokens once
expired. Let me know if we already have any best
practice with glusterd to client communication.<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Vijay<br>
<br>
[1] <a moz-do-not-send="true"
href="http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md"
rel="noreferrer" target="_blank">http://review.gluster.org/#/c/<wbr>13214/6/under_review/managemen<wbr>t_rest_api.md</a><br>
</blockquote>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Pranith<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>