regards
Aravinda
On Tuesday 23 August 2016 09:32 PM, Pranith Kumar Karampuri wrote:
On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avish...@redhat.com
<mailto:avish...@redhat.com>> wrote:
Today I discussed about the topic with Rajesh, Avra and Kotresh.
Summary as below
- 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.
- Gluster Clients to Glusterd using RPC, Glusterd will send
message to local eventsd.
Any suggestions for this approach?
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?
- No extra auth required other than existing glusterd communication
- Backup volfile server for sending message to other glusterd of server
if one server is down
- Events traffic is not heavy two hops may be acceptable(?)
regards
Aravinda
On Thursday 04 August 2016 11:04 AM, Aravinda wrote:
regards
Aravinda
On 08/03/2016 09:19 PM, Vijay Bellur wrote:
On 08/02/2016 11:24 AM, Pranith Kumar Karampuri wrote:
On Tue, Aug 2, 2016 at 8:21 PM, Vijay Bellur
<vbel...@redhat.com <mailto:vbel...@redhat.com>
<mailto:vbel...@redhat.com
<mailto:vbel...@redhat.com>>> wrote:
On 08/02/2016 07:27 AM, Aravinda wrote:
Hi,
As many of you aware, Gluster Eventing feature
is available in
Master.
To add support to listen to the Events from
GlusterFS Clients
following
changes are identified
- Change in Eventsd to listen to tcp socket
instead of Unix domain
socket. This enables Client to send message to
Eventsd running in
Storage node.
- On Client connection, share Port and Token
details with Xdata
- Client gf_event will connect to this port
and pushes the
event(Includes Token)
- Eventsd validates Token, publishes events
only if Token is valid.
Is there a lifetime/renewal associated with this
token? Are there
more details on how token management is being
done? Sorry if these
are repeat questions as I might have missed
something along the
review trail!
At least in the discussion it didn't seem like we
needed any new tokens
once it is generated. Do you have any usecase?
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]?
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.
Thanks,
Vijay
[1]
http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md
<http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md>
--
Pranith
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
