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

[Atin Mukherjee]

On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avishwan at 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?
>

While this implementation might be easy, but I don't think from an
architecture and design perspective this stands correct (initially I
actually thought about it too).  Consumers of gf_event () should be able to
find a way to directly communicate to the eventsd and for that
establishment GlusterD can be queried for the first time, but not every
time.

Kaushal - your thoughts?

>
> 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/managemen
>>> t_rest_api.md
>>>
>>
>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 

--Atin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160824/1e8912c0/attachment.html>