[Gluster-devel] Events API: Adding support for Client Events

[Aravinda]

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?

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 <vbellur at redhat.com
>>> <mailto:vbellur at 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
>